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Real Party in Interest 



Mainline Corporate Holdings, Limited, an Irish Company is the 
real party in interest and the assignee of this application. 
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Related Appeals and Interferences 

Appellant is aware of no related appeals, interference, and/ 
other proceedings relevant to this discussion. 
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Status of Claims 

Claims 1-8, 10, 12-23, 25-40, of which claims 1, 10, 23, and 
37 are independent claims, are presented herein. Claims 1-8, 
10, 12-23, 25-40 have been rejected, and claims 1-8, 10, 12-23, 
25-40 are on appeal. 

Appendix A provides a clean copy of all claims on appeal. 

Claims 1, 3, 10, 12, 23, and 25 stand rejected under 35 
U.S.C. 102(e) as being anticipated by Boesch et al . , U.S. Patent 
No. 5,870,473 (hereinafter Boesch) . 

Claims 4-8, 13-16, and 26-30 stand rejected under 35 U.S.C. 
103(a) as being unpatentable over Boesch in view of Boston, EP 
0251619. 

Claims 17-22 and 31-37 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Boesch and Boston in view of Levine et 
al., WO 95/12169 (hereinafter Levine). 

Although not expressly stated, claims 38-40 are presumed to 
be rejected under 35 U.S.C. 103(a) as being unpatentable over 
Boesch and Boston in view of Levine. 

Appendix B provides copies of the Boesch, Boston, and Levine 

references . 
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Status of Amendments 



No amendments have been filed subsequent to the reject! 
set forth in a final Office Action, dated 1 June 2006. 
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Suinmarv of Claimed Sub ject Matter 

Appendix C provides copies of drawing sheets 1-10 containing 
FIGs. 1-10, some of which are discussed herein. 

in accordance with at least one embodiment, the present 
invention pertains to a data processing method, data processing 
system, and a computer program for determining a preferred 
currency for association with a payment card transaction between 
a merchant and a payment card cardholder. This embodiment of 
the present invention is therefore directed at automatically 
determining the currency of a charge, debit or credit card used 
in a transaction between a cardholder and a merchant and 
associating the determined currency with the transaction, so 
that a cardholder may conduct the transaction in a currency 
which differs from the currency ordinarily used by the merchant, 
with no input required from the merchant. 

The elements of each of the independent claims, mapped to 
the specification by page number and line number and mapped to 
the drawings, are presented below. 

Independent Claim 1 

The preamble of claim 1 recites a "data processing method 
performed in a data processing system for determining a 
preferred currency for association with a payment card 
transaction between a merchant and a payment card cardholder." 
The data processing method is generally discussed on page 10, 
line 6-31, and is illustrated in Figure 5. Figure 5 illustrates 
a flowchart of the operation of the present invention, 
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specifically a task 54, in combination with conventional 
methodology at a task 53 . The data processing method is 
discussed in greater detail on page 14, line 16, through page 
16, line 16, and is shown in FIG. 8. The software and/or 
hardware for performing the steps according to the invention are 
at a data processing system which may be a terminal, payment 
router, an authorization host, or any combination of these, as 
disclosed at page 12, lines 1-3. 

A first claim element recites "obtaining the card number of 
the payment card." An obtaining operation 205 is discussed in 
the specification at page 14, lines 16-20, and is illustrated in 
FIG. 8. The card number is obtained when the merchant swipes 
205 the card in the magnetic stripe reader of the point of sale 
terminal . 

A second claim element recites "in said data processing 
system, identifying an identifier code from said card number." 
An operation 50 is discussed in the specification at page 10, 
lines 6-8, and shown in FIG. 5, in which an identifier code is 
extracted from the payment card details. 

A third claim element recites "determining the operating 
currency for said identifier code by comparing said identifier 
code with entries in a table wherein each entry in said table 
contains an issuer identifier code or range of issuer identifier 
codes and a corresponding currency code." An operation 51 is 
discussed in the specification at page 10, lines 16-30, and is 
shown in FIG. 5. The identifier code is compared 51 with 
entries in a bank reference table, an example of which is shown 
in FIG. 6, which contains a list of issuer identifier codes. 
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Each issuer identifier code 60(l-n) in the table of FIG. 6 has 
an associated entry 61(l-n) containing an associated currency, 
which corresponds to the currency of payment cardholders 
accounts of the issuer. If an entry is found in the bank 
reference table for the identifier code, the operating currency 
is determined by extracting the associated currency 
corresponding to the issuer code. A similar operation 210 is 
discussed in the specification at page 14, lines 22-23, and is 
shown in FIG. 8. The terminal software searches through the 
Bank Reference table and checks 210 for an entry corresponding 
to the issuer (identifier) code from the card number to 
determine the operating currency. 

A fourth claim element recites "setting the currency for 
association with the payment card transaction as the determined 
operating currency for the identifier code." The claimed 
setting element is discussed in general terms at page 10, lines 
26-30, and elements 52, 53, and 54, shown in FIG. 5. The 
claimed setting element is discussed in the specification in 
more specific terms at page 14, lines 23-26, and shown in FIG. 
8. That is, if an entry is found the currency for the operation 
is set 215 to that of the payment card. If no entry in the Bank 
Reference table is found the currency is set 220 to that of the 
merchant . 

Independent Claim 10: 

The preamble of claim 10 recites a "data processing system 
for determining a preferred currency for association with a 
payment card transaction, the payment card having a card number, 
between a merchant and a payment card cardholder." One data 
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processing system is exemplified as being a point of sale 
terminal 70 discussed in the specification on page 12, line 5, 
through page 13, line 14. The terminal 70 executes the 
methodology discussed in connection with claim 1 which is" 
discussed in the specification at page 14, line 16, through page 
16, line 16. 

A first claim element of claim 10 recites "means for 
obtaining the card number of the payment card from the 
cardholder." The terminal includes a magnetic strip reader 71 
and an alphanumeric and function keypad 72, which are discussed 
in the specification at page 12, lines 15-18, and shown in FIG. 
7. Card details (card number, expiry date, and name of the 
cardholder) are obtained 205 either by swiping a payment card 
through the magnetic strip reader 71 or using the keypad 72. 

A second claim element of claim 10 recites "means for 
identifying an identifier code from said card number." The 
terminal software includes code which caries out functions that 
include: modem control, card reading, bank reference table 
management, and so forth, as discussed in the specification at 
page 12, line 27, through page 13, line 31. The specification 
further discusses the terminal software obtains an identifier 
code from the card number at page 14, lines 23-26. 

A third claim element of claim 10 recites "means for 
determining the operating currency for said identifier code by 
comparing said identifier code with entries in a table, wherein 
each entry in said table contains an issuer identifier code or 
range of issuer identifier codes and a corresponding currency 
code." The specification discusses the terminal software 



APPELLANT'S BRIEF 
Serial No. 09/613,679 
Page 10 



searches through the Bank Reference table (shown in FIG. 6) and 
checks for an entry corresponding to the code obtained from the 
card number at page 14, lines 22-23. 

A fourth claim element of claim 10 recites "means for setting 
the currency for association with the payment card transaction 
as the determined operating currency for the identifier code . '< 
Applicants specification teaches at page 14, lines 23-26 that if 
an entry is found the currency for the transaction is set 215 to 
that of the payment card. If no entry in the Bank Reference 

•~ 9on t-n i-hat of the merchant, 

table is found the currency is set 220 to tnau 

Independent Claim 23: 

The preamble of claim 23 recites a computer program encoding 
a set of computer instructions for use in a computing device for 
determining a preferred currency for association with a payment 
card transaction, the payment card having a card number, between 
a merchant and a payment card cardholder. A first claim element 
of claim 23 recites a computer code section which when executed 
on the computing device obtains the card number of the payment 
card from the cardholder. A second claim element recites a 
computer code section which when executed on the computing 
device identifies an identifier code from said card number. A 
third claim element recites a computer code section which when 
executed on the computing device determines the operating 
currency for said identifier code, by comparing said identifier 
code with entries in a table, wherein each entry in said table 
contains an issuer identifier code or range of issuer identifier 
codes and a corresponding currency code. A fourth claim element 
recites a computer code section which when executed on the 
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computing device sets the currency for association with the 
payment card transaction as the determined operating currency 
for the identifier code. 

The computer code sections correspond with the method 
operations recited in claim 1 and the specification teaches that 
software and/or hardware performs the steps according to the 
invention at page 12, lines 1-3. The claimed computer program 
is software. Similarly, the claimed computer code sections are 
also software. These code sections are discussed in terms of 
the methodology discussed on page 14, line 16, through page 16, 
line 16, and shown in FIG. 8. Consequently, these claim 
elements have been previously mapped to the specification and 
drawings above and are not repeated for brevity. 

Independent claim 37: 

The preamble of claim 37 recites a "method of operating a 
data processing system to conduct a financial transaction for 
the exchange of money provided by a payment card cardholder for 
a good or service provided by a merchant." The obtaining, 
identifying, and determining operations are similar to those set 
forth in connection with claim 1. Consequently, these claim 
elements have been previously mapped to the specification and 
drawings above and are not repeated for brevity. 

A fourth element of claim 37 recites "indicating said 
operating currency as being a preferred currency of exchange for 
said financial transaction." This operation utilizes slightly 
different language than recited in claim l. Nevertheless, the 
indicating operation is discussed in the specification at page 
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14, lines 23-26, wherein the preferred currency of exchange is 
indicated as 1) if an entry is found the currency for the 
transaction is set 215 to that of the payment card or 2) if no 
entry in the Bank Reference table is found the currency is set 
220 to that of the merchant. 

A fifth element of claim 37 recites "receiving a cardholder 
reply in response to said indicating activity" and a sixth 
element of claim 37 recites "completing said financial 
transaction in response to said receiving activity." A 
cardholder reply is discussed in the specification at page 15, 
lines 7-16 and is shown in FIG. 8. A reply by the cardholder 
entails a consent to or rejection of an offer at 270. When the 
cardholder consents to the offer at 270, the financial 
transaction is completed in the currency of the cardholder, as 
discussed in the specification at page 15, line 15, through page 
16, line 16. 

Dependent claims 3, 12, 25: 

Claims 3, 12, and 25 share similar features. In particular, 
each of claims 3, 12, and 25 include the feature of the 
preferred currency being set to a default currency of the 
merchant when no operating currency can be determined for the 
identifier code. This feature is discussed in the specification 
at page 14, lines 24-26, and is shown in FIG. 8 at element 220. 

Dependent claims 4, 14, 26: 

Claims 4, 14, and 26 share similar features. In particular, 
each of claims 4, 14, and 26 include the features of the 
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cardholder being prompted as to whether the transaction is to be 
conducted in the preferred currency, converting the transaction 
amounts to equivalent amounts in the preferred currency, and 
presenting these amounts for review by the cardholder. This 
feature is discussed in the specification at page 15, lines 7- 
16, and is shown in FIG. 8 at elements 265, 270, and 275. 

Dependent claims 5 and 27: 

Claims 5 and 27 share similar features. In particular, each 
of claims 5 and 27 include the feature of at least one of the 
transaction amounts is converted to an equivalent amount in the 
preferred currency and is presented to the cardholder. This 
feature is discussed in the specification at page 16, line 6-16, 
and is shown in FIG. 8. A transaction slip is produced 260 
which details transaction values in the merchant currency, 
transaction value in cardholders currency, and other 
information. A copy of this transaction slip is produced for 
the merchant and the cardholder. 
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Grounds of Rejection to Be Reviewed on Appeal 

The 1 June 2006 Final Office Action rejects claims 1, 3, 10, 
12, 23, and 25 under 35 U.S.C. 102(e) as being anticipated by 
Boesch. In addition, claims 4-8, 13-16, and 26-30 were rejected 
under 35 U.S.C. 103(a) as being unpatentable over Boesch in view 
of Boston, and claims 17-22, 31-37, and 38-40 were rejected 
under 35 U.S.C. 103(a) as being unpatentable over Boesch and 
Boston in view of Levine. 

These rejections are formally delineated in the Status of 
Claims section of this document. 

The following three grounds of rejection are presented for 
review : 

1: Whether claims 1, 3, 10, 12, 23, and 2 5 are unpatentable 
under 35 U.S.C. 102(e) as being anticipated by Boesch. 

2: Whether claims 4-8, 13-16, and 26-30 are unpatentable under 
35 U.S.C. 103(a) over Boesch in view of Boston. 

3: Whether claims 17-22 and 31-40 are unpatentable under 35 
U.S.C. 103(a) over Boesch and Boston in view of Levine. 
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Arguments 

Grounds of Rejection 1 -- Claims 1, 3, 10, 12, 23, and 25 

Independent Claims 1, 10, and 23: 

Regarding claim 1, the 1 June 2006 final Office Action to 
this application alleges that Boesch teaches a data processing 
method performed in a data processing system for determining a 
preferred currency for association with a payment card 
transaction between a merchant and a payment card cardholder. 
The final Office Action cites a passage at col. 11, lines 26-65, 
and Figures 4K and 5H as an alleged teaching of the claim 1 
limitation of obtaining the card number of the payment card. 
The final Office Action cites a passage at col. 12, lines 16-18, 
as an alleged teaching of the claim 1 limitation of the data 
processing system, identifying an identifier code from the card 
number. In addition, the final Office Action cites a passage at 
col. 12, line 50, through col. 13, line 10, as an alleged 
teaching of the claim 1 limitation of determining the operating 
currency for the identifier code by comparing the identifier 
code with entries in a table, wherein each entry in the table 
contains an issuer identifier code or range of issuer identifier 
codes and a corresponding currency code. The final Office 
Action also cites a passage at col. 14, lines 17-30, as an 
alleged teaching of the claim 1 limitation of setting the 
currency for association with the payment card transaction as 
the determined operating currency for the identifier code. 

Boesch discloses a sophisticated system under which customer 
purchases from merchants may be securely made over the Internet. 
The thrust of the disclosure is directed toward providing secure 
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communications. In one embodiment, the secure communications 
occur through an electronic transfer system in which a customer 
and a merchant can conduct a transaction whereby the customer 
can purchase a product from the merchant and pay for the product 
using electronic cash. 

Boesch teaches of a customer paying for products with 
electronic cash, and defines electronic cash as being a 
representation of funds (real cash, credit, etc.), at col. 6, 
lines 51-53. In order to pay for products with electronic cash, 
Boesch further teaches that a customer "loads" funds associated 
with a bound instrument (credit card, debit card, demand deposit 
account, or other financial instruments) to a persona of the 
customer user (col. 7, lines 53-58). The electronic cash is 
subsequently "unloaded" (or transferred) from the persona of the 
customer user to another bound instrument, such as that of a 
merchant. In other words, funds are "loaded" into and 
"unloaded" from a cash container (col. 21, lines 16-24). 

The Boesch teaching of electronic cash is consistent with 
conventional definitions of electronic cash, electronic money, 
electronic currency, digital currency, and the like which refers 
to money which is represented, held, and exchanged only in 
electronic form. Some examples of the use of electronic cash 
include internet/online banking, debit cards, online bill 
payments and internet business. Disadvantages to the use of 
electronic cash include fraud, failure of the technology, 
possible tracking of individuals, and the like. Boesch attempts 
to solve some of these problems by implementing a system and 
method for increasing the efficiency of secure message 
processing when paying for a product using electronic 
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funds/cash. 

In contrast, Appellant's invention as defined in claim 1 is 
directed toward a method "for determining a preferred currency 
for association with a payment card transaction between a 
merchant and a payment card cardholder." Appellant describes a 
payment card transaction as a transaction in which a physical 
medium, i.e., a payment card, such as a credit card, charge 
card, debit card, and the like, is utilized by a cardholder of 
the payment card to make a purchase. Appellant's teaching is 
consistent with conventional definitions of the term payment 
card. In particular, a payment card covers a range of different 
cards that can be presented by a cardholder to make a payment . 
A payment card is typically backed by an account holding funds 
belonging to the cardholder or offering credit to the 
cardholder. 

Consequently, the Boesch teaching of an electronic cash 
transaction (in which funds are "loaded" to a persona, or cash 
container, associated with a customer user) between a merchant 
user and a customer user is not a teaching of a "payment card 
transaction between a merchant and a payment card cardholder" as 
recited in independent claim 1. While the Office Action alleges 
that Boesch teaches a payment card transaction, this allegation 
is a distortion and misrepresentation of that which Boesch 
actually teaches. That is, the merchant user and customer user 
within the Boesch system engage in an electronic cash 
transaction, which is not a payment card transaction. Indeed, 
the merchant user has no knowledge of any particular payment 
card held by the payment card cardholder or other mode of 
payment other than electronic cash. 
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Nor is Boesch directed toward currency determination for a 
payment card transaction between a merchant and a customer. The 
"determining" operation of independent claim 1 determines the 
operating currency for the identifier code by comparing the 
identifier code with entries in a table wherein each entry in 
the table contains an issuer identifier code or range of issuer 
identifier codes and a corresponding currency code. The 
"setting" operation of independent claim 1 then sets the 
currency for association with the payment card transaction as 
the determined operating currency for the identifier code. 

Boesch does not teach Appellant's "determining" operation 
despite Office Action allegations to the contrary. The passage 
cited from Boesch at col. 12, line 50, through col. 13, line 10, 
as an alleged teaching of Appellant's "determining" operation 
discloses a portion of a server persona data structure 12 0 that 
stores data relating to the customer users and merchant users 
that have registered with the Boesch electronic transfer system. 
A portion of the server persona data structure 12 0 is 
illustrated in FIG. 4D. In particular, the cited passage and 
associated FIG. 4D discloses a table of data illustrating fields 
of instrument binding data 12 OH. A "persona" of the Boesch 
reference is essentially a collection of data relating to a 
specific customer user or merchant user. The instrument taught 
by Boesch is a financial instrument, and may include a credit 
card, debit card, demand deposit account (DDA) , or the like. 

Boesch teaches in the cited passage that instrument binding 
data 120H includes a field 120H.16 having a flag indicating 
whether the bound instrument is enabled for sale transactions, 
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and when field 120H.16 indicates that the bound instrument is 
enabled for sale transactions, a limit in customer user's chosen 
(i.e., native) currency is stored in field 120H.17. Instrument 
binding data 120H also includes a field 120H.18 indicating 
whether the bound instrument is enabled for credit/return 
transactions. A credit/return transaction is an operation where 
a merchant credits the customer persona 120.1 in lieu of 
providing the product originally agreed to. When field 120H.18 
indicates that the bound instrument is enabled for credit/return 
transactions, a limit in customer user's chosen (native) 
currency, per credit/return transaction, is stored in a field 
120H.19. 

The Boesch instrument binding data 12 OH is illustrated as a 
table in Figure 4D, and of course, a table typically has 
entries. However, Appellant's determining operation of claim 1 
recites determining the operating currency for the identifier 
code by comparing the identifier code with entries in a table 
wherein each entry in the table contains an issuer identifier 
code or a range of issuer identifier codes and a corresponding 
currency code. Thus, even if one somehow equates the data 
structure 120 of instrument binding data 120H with Appellant's 
claimed table, the instrument binding data 120H is still lacking 
entries wherein each entry contains an issuer identifier code or 
range of issuer identifier codes and a corresponding currency 
code. Rather, the Boesch table/data structure merely indicates 
that a user's chosen (native) currency for some operations may 
be specified. As stated in W.L. Gore & Associates v. Garlock 
Inc . , 220 USPQ 303, 313 (Fed. Cir. 1983), cert, denied, 469 U.S. 
851 (1984) : 



APPELLANT'S BRIEF 
Serial No. 09/613,679 
Page 2 0 

Anticipation requires the disclosure in a single 
prior art reference of each element of the claim under 
consideration . 

Boesch simply does not anticipate Appellant's invention of 
claim 1 because Boesch does not disclose a payment card 
transaction between a merchant and a payment card cardholder. 
Moreover, since the Boesch table of instrument binding data 12 OH 
is lacking the claimed entries wherein each entry in the table 
contains an issuer identifier code or a range of issuer 
identifier codes and a corresponding currency code, no 
comparison can be made between an identifier code identified 
from the card number of the payment card and these absent 
entries in order to determine the operating currency for the 
identifier code. As such, the rejection of independent claim 1 
under 35 U.S.C. §102 (a) was improper. 

Nor is Appellant's invention as defined in claim 1 obvious in 
view of Boesch. It should be noted that an "identifier code" is 
defined in Appellant's specification as the portion of a card 
number of a payment card which distinguishes it between card 
issuers. An "issuer identifier code" is defined in Appellant's 
specification as a code contained in Appellant's claimed table, 
also known as a bank reference table ( ' BRT ' ) . This issuer 
identifier code is associated with a currency in the claimed 
table. The associated currency corresponds to the currency of 
the payment card cardholder accounts for the issuer identified 
by the issuer identifier code. Thus, Appellant's claimed table 
(BRT) contains multiple entries of issuer identifier codes and 
corresponding currency codes. 

The Boesch reference teaches that a customer-merchant 
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transaction may take place in a multiple currency environment. 
But that teaching falls far short of suggesting how the currency 
is set, as recited in claim 1. How the currency is set, in 
accordance with claim 1, is through a comparison made between 
the identifier code from the card number of the payment card and 
entries presented in the table to determine an operating 
currency. 

In contrast, Boesch expressly teaches how a currency is set 
for the Boesch system and that is through explicit customer 
entry of a default currency by the customer user during a 
registration process (col. 80, lines 5-26). This registration 
process occurs prior to binding a financial instrument, such as 
a bank account, credit card, or debit card, for use during 
electronic cash transactions. Consequently, the Boesch default 
currency corresponds with the customer user's chosen preference 
regardless of any financial instrument bound to that customer's 
persona in the Boesch electronic transfer system. 

Therefore, no table of entries containing issuer identifier 
codes and corresponding currency codes, such as that recited in 
claim 1, is required in the system of Boesch. The explicit 
customer entry of a default currency during a registration 
process as taught by Boesch suggests away from Appellant's 
invention of claim 1 in which a comparison is made between the 
identifier code identified from the card number of the payment 
card and entries in the table to determine an operating 
currency, and the currency is set for association with the 
payment card transaction as the determined operating currency. 



The invention of claim 1 is directed to a method for 
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automatically determining a preferred currency for association 
with a payment card transaction that requires no user input. 
The automatic character of the claimed data processing method is 
intrinsic as a result of performing the claimed steps of 
obtaining, identifying, determining the operating currency 
utilizing a table containing issuer identifier codes and 
corresponding currency codes, and setting the currency for the 
payment card transaction as the determined operating currency 
for the identifier code. The pre-emptive, explicit customer 
entry of a default currency in the Boesch system during a 
registration process before conducting any transaction is not 
automatic since input from the customer/user/cardholder at a 
stage preceding a transaction is necessary. 

For the purposes of the Boesch system, explicit customer 
entry of a default currency during a registration process 
executed prior to binding a particular financial instrument 
(bank account, credit card, debit card, etc.) is sufficient. 
That is, there is no motivation or suggestion to modify the 
Boesch system to include Appellant's claimed table containing 
entries of issuer identifier codes and a corresponding currency 
codes because such a table would serve no purpose in the Boesch 
system. 

It is only Appellant's specification that teaches of a data 
processing method performed in a data processing system for 
determining a preferred currency for association with a payment 
card transaction between a merchant and a payment cardholder, as 
recited in claim 1. Moreover, it is only Appellant's 
specification that teaches of determining the operating currency 
for an identifier code identified from a card number of the 
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payment card by comparing the identifier code with entries in a 
table wherein each entry in the table contains an issuer 
identifier code or range of issuer identifier codes and a 
corresponding currency code, and setting the currency for 
association with the payment card transaction as the determined 
operating currency for the identifier code. Appellant's 
invention of claim 1 provides means by which a cardholder can be 
sure of an exact value of a payment card transaction when 
traveling abroad by allowing the cardholder to make payments 
and/or view a transaction amount in their home currency rather 
than in the currency of the merchant with whom they are 
conducting business. Consequently, Appellant's invention as 
defined in claim 1 is not rendered obvious in view of the Boesch 
reference . 

Unlike claim 1, claim 10 is expressed in the terms of a 
system. But in spite of certain differences, claims 1 and 10 
share some similar features. For example, claim 10 includes the 
limitations of means for determining the operating currency for 
the identifier code by comparing the identifier code with 
entries in a table, wherein each entry in the table contains an 
issuer identifier code or range of issuer identifier codes and a 
corresponding currency code, and means for setting the currency 
for association with the payment card transaction as the 
determined operating currency for the identifier code. 
Accordingly, claim 10 is neither anticipated by nor rendered 
obvious in view of Boesch for substantially the same reasons as 
are set forth above in connection with claim 1. 



Unlike claim 1, claim 23 is expressed in the terms of a 
computer program. But in spite of certain differences, claim 23 
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also shares some similar features with claim 1, including the 
features generally discussed above in connection with claim 1. 
Accordingly, claim 23 is neither anticipated by nor rendered 
obvious in view of Boesch for substantially the same reasons as 
are set forth above in connection with claim 1. 

For the reasons set forth above, the rejection of independent 
claims 1, 10, and 23 under 35 U.S.C. §102 (e) as being 
anticipated by Boesch was improper. In addition, claims 1, 10, 
and 2 3 are not obvious in view of Boesch. Appellant therefore 
believes independent claims 1, 10, and 23 to be allowable. 
Accordingly, the Board is respectfully requested to reconsider 
claims 1, 10, and 23. 

Claims 3, 12, and 25: 

Claim 3 depends from independent claim 1. While the previous 
discussion was specifically directed to independent claim 1, the 
limitations of claim 1 are read into dependent claim 3. 
Accordingly, claim 3 is believed to be allowable by reason of 
dependency. Claim 3 also includes the further limitation 
wherein the preferred currency is set to a default currency of 
the merchant when no operating currency can be determined for 
the identifier code. The Final Office Action cites a passage in 
Boesch at col. 13, lines 3-33 as an alleged teaching of 
Appellant's invention of claim 3. 

As discussed in detail in connection with claim 1, no 
operating . currency can be determined for the identifier code, 
because Boesch fails to teach or suggest Appellant's limitations 
of claim 1 of comparing the identifier code with entries in a 
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table, and each entry containing an issuer identifier code or 
range of issuer identifier codes and a corresponding currency 
code . 

In addition, Appellant respectfully disagrees with the Office 
Action allegation that Boesch teaches the further limitation of 
claim 3. There is no teaching or suggestion within the Boesch 
reference of setting the preferred currency of the merchant 
because there is no table taught by Boesch that even remotely 
resembles Appellant's claimed table having entries wherein each 
entry in the table contains an issuer identifier code or range 
of issuer identifier codes and a corresponding currency code. 

The passage cited in col. 13, lines 3-33, as an alleged 
teaching of Appellant's limitations of claim 3 merely indicates 
that within the set of fields 120H. 1-120H . 28 that store data for 
each financial instrument bound to customer persona 120.1, and 
particularly within fields 120H.19, 120H.21, and 120H.23, 
certain limits may be set in a customer user's chosen native 
currency . The passage further teaches that if a native currency 
does not exist, the limit may be set in U.S. dollars. However, 
the customer user's chosen native currency is not a teaching of 
the preferred currency being set to a default currency of the 
merchant when no operating currency can be determined for the 
identifier code, as recited in claim 3, because the merchant 
need not have the same currency as the customer user. Likewise, 
the currency set in U.S. dollars is not a teaching of the 
preferred currency being set to a default currency of the 
merchant when no operating currency can be determined for the 
identifier code because the merchant need not be a U.S. merchant 
that deals in U.S. currency. As stated in W.L. Gore & 
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Associates, Inc. v. Garlock, Inc. , 220 USPQ 303, 312-13 (Fed. 
Cir. 1983), cert denied, 469 U.S. 851 (1984): 

To imbue one of ordinary skill in the art with 
knowledge of the invention in suit, when no prior art 
reference or references of record convey or suggest that 
knowledge, is to fall victim to the insidious effect of a 
hindsight syndrome wherein that which only the inventor 
taught is used against its teacher. 

It would be through hindsight gained through an understanding 
of Appellant's specification and claims that one could even 
consider setting a preferred currency to a default currency of 
the merchant when no operating currency can be determined for 
the identifier code especially in the absence of a teaching or 
suggestion of Appellant's claimed table having entries wherein 
each entry in the table contains an issuer identifier code or 
range of issuer identifier codes and a corresponding currency 
code. Of course, it is improper to use hindsight in making an 
obviousness rejection. Consequently, Appellant believes that 
Boesch fails to teach or suggest the limitations of claim 3. 

Claim 12 depends from independent claim 10, and claim 25 
depends from independent claim 23. Appellant therefore believes 
claims 12 and 25 to be allowable by reason of dependency. In 
addition, claims 12 and 25 share similar features with claim 3. 
Consequently, Appellant believes that Boesch fails to teach or 
suggest the limitations of claims 12 and 25 for the reasons set 
forth in connection with claim 3. 

For the reasons set forth above, the rejection of claims 3, 
12, and 25 under 35 U.S.C. §102 (e) as being anticipated by 
Boesch was improper. Nor are claims 3, 12, and 25 rendered 
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obvious in view of Boesch. Appellant therefore believes claims 
3, 12, and 25 to be allowable. Accordingly, the Board is 
respectfully requested to reconsider claims 3, 12, and 25. 

Grounds of Rejection 2 Claims 4-8, 13-16, and 26-30 

Claims 4-8, depend directly or indirectly from independent 
claim 1. While the previous discussion was specifically 
directed to independent claim 1, the limitations of claim 1 are 
read into dependent claims 4-8. Accordingly, claims 4-8 are 
believed to be allowable by reason of dependency. Claims 13-16 
depend directly or indirectly from independent claim 10. 
Accordingly, claims 13-16 are also believed to be allowable by 
reason of dependency. Similarly, claims 2 6-30 depend from 
independent claim 23, and are also believed to be allowable by 
reason of dependency. In addition, claims 4-8, 13-16, and 26-30 
are allowable for independent reasons. 

Claims 4, 14, and 26: 

Claim 4 includes the limitation wherein the cardholder is 
prompted as to whether the transaction is to be conducted in the 
preferred currency, including the steps of converting the 
transaction amounts to equivalent amounts in the preferred 
currency and presenting these amounts for review by the 
cardholder . 

The final Office Action acknowledges that Boesch fails to 
teach the limitations of claim 4. However, the final Office 
Action alleges that Boston teaches the features of claim 4, 
citing a passage on page 5, paragraphs 3 and 4, and concludes 
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that it would have been obvious to modify Boesch to include the 
alleged teaching of Boston because such a modification would 
allow Boesch to have the transaction amount expressed in the 
foreign currency using the associated conversion rate. 

The present invention is concerned with effecting 
transactions in a multicurrency environment. Within the context 
of the present invention, for any individual merchant, 
individual transactions may take place using any one of a number 
of different currencies. As is discussed in more detail below, 
Appellant's claims define an invention that permits a payment 
card transaction to take place between a merchant and a customer 
using the customer's preferred currency. 

Boston does not disclose such a system. Rather, Boston 
discloses a system in which transactions take place exclusively 
in the currency of the merchant. More specifically, Boston 
fails to provide any teachings pertaining to converting the 
transaction amounts to equivalent amounts in the preferred 
currency and presenting these amounts for review by the 
cardholder, as recited in claim 4. Instead, Boston teaches the 
opposite . 

Boston discloses a transaction card that includes a processor 
and a memory in which a transaction limit represented in a base 
currency and one or more rates for converting the base currency 
into different foreign currencies can be stored. The Boston 
card is further configured with data input means for allowing 
the cardholder to select the desired currency and for updating 
the transaction limit and conversion rates. The passage on page 
5, paragraphs 3 and 4, of the Boston reference cited in the 
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final Office Action teaches that when a transaction is to be 
carried out in a foreign currency, the processor will convert 
the transaction limit from the base currency into a transaction 
limit represented in the foreign currency using the associated 
conversion rate. The Boston system can then compare a 
transaction amount expressed in the foreign currency and 
supplied through data entry to the converted transaction limit 
to determine if the transaction should be approved. Thus, the 
multi-currency capability of the Boston system is limited to 
expressing a transaction limit in one or more of several 
currencies, for verifying and/or validating a transaction, 
possibly as part of a transaction authorization procedure. That 
is, Boston does not associate the currency of the card with the 
transaction, i.e., change the currency of the transaction from 
the merchant currency to the cardholder currency at the point of 
sale . 

The Boston transaction amounts are not converted to 
equivalent amounts in the preferred currency. Rather, the 
cardholder enters the foreign currency and transaction limits in 
the base currency. The transaction limits are subsequently 
converted from the base currency to the foreign currency. The 
converted transaction limits are then compared with the 
unconverted transaction amounts in the foreign currency. Since 
the Boston transaction amounts are not converted to equivalent 
amounts in the preferred currency, as recited in claim 4, it 
follows that these equivalent amounts cannot be presented for 
review by the cardholder, as also recited in claim 4. 

Well-established patent practice dictates that a combination 
of prior art references cannot render obvious that which none of 
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the prior art teaches or suggests. As stated in In re Wood , 202 
USPQ 171, 174, (C.C.P.A. 1979) : 

The test for obviousness is not whether the features 

of one reference may be bodily incorporated into another 

ref erence .... Rather , we look to see whether combined 

teachings render the claimed subject matter obvious. 

Accordingly, the proper evaluation for determining 
patentability is to consider whether the prior art, and not 
Appellant's specification, suggests modifications which make the 
prior art methodology more closely resemble Appellant's data 
processing method and system. Moreover, proper evaluation for 
determining patentability is to consider whether combined 
teachings render the claimed subject matter obvious. 

Claim 4 recites operations that go beyond anything disclosed 
or suggested in either Boesch or Boston. Accordingly, together 
Boesch and Boston cannot be interpreted to suggest that which 
neither alone suggests. As such, claim 4 is believed to be 
allowable for the reasons set forth above. Claims 13 and 26 
share similar features with claim 4. Consequently, a 
combination of Boesch and Boston fails to render obvious the 
inventions of claims 13 and 26 for the reasons set forth in 
connection with claim 4 and claims 13 and 26 are believed to be 
allowable. The Board is respectfully requested to reconsider 
claims 4, 13, and 26. 

Claims 5-7 and 27-29: 

Claim 5 includes the limitation wherein at least one of the 
transaction amounts is converted to an equivalent amount in the 
preferred currency and is presented to the cardholder. Claim 5 
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is believed to be allowable for reasons similar to those set 
forth in claim 4. As explained above, it is the transaction 
limits that are converted from the base currency to the foreign 
currency, as opposed to the at least one of the transaction 
amounts which are actually converted to an equivalent amount in 
the preferred currency, as recited in claim 5. The converted 
transaction limits are then compared with the unconverted 
transaction amounts in the foreign currency. 

Since the Boston transaction amount (s) are not converted to 
an equivalent amount in a preferred currency, as recited in 
claim 5, it follows that the equivalent amount in the preferred 
currency cannot be presented to the cardholder, as also recited 
in claim 5. 

Claim 5 recites operations that go beyond anything disclosed 
or suggested in either Boesch or Boston. Accordingly, together 
Boesch and Boston cannot be interpreted to suggest that which 
neither alone suggests. As such, claim 5 is believed to be 
allowable for the reasons set forth above. Claim 27 shares 
similar features with claim 5. Consequently, a combination of 
Boesch and Boston fails to render obvious the invention of claim 
27 for the reasons set forth in connection with claim 5 and 
claim 27 is believed to be allowable. 

Claims 6 and 7 depend from claim 5 and are believed allowable 
for the reasons set forth above in connection with claims 1 and 
5. Likewise, claims 28 and 29, depend from claim 27 and are 
believed allowable for the reasons set forth above in connection 
with claims 23 and 27. Accordingly, the Board is respectfully 
requested to reconsider claims 5-7 and 27-29. 
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Grounds of Rejection 3 -- Claims 17-22 and 31-40 

Claims 31 and 32, depend from independent claim 1 and the 
limitations of claim 1 are read into dependent claims 31 and 32. 
Accordingly, claims 31 and 32 are believed to be allowable by 
reason of dependency. Claims 17-22, 33, and 34 depend directly 
or indirectly from independent claim 10. Accordingly, claims 
17-22, 33, and 34 are also believed to be allowable by reason of 
dependency. Similarly, claims 35 and 36 depend from independent 
claim 23, and are also believed to be allowable by reason of 
dependency. Independent claim 3 7 includes features similar to 
those set forth in connection with claim 1, and is believed to 
be allowable for the reasons set forth in connection with claim 
1. Claims 38-40 depend directly or indirectly from claim 37, 
and are believed allowable by reason of dependency. 

Levine teaches a method and apparatus for distributing 
currency. Levine specifically teaches a magnetic stripe, 
electronic traveler's check (ETC) card issued to a customer and 
having a customer- selectable monetary value. The customer- 
selectable monetary value is configured with an encoded card 
number, including a bank identification number and an account 
number . 

The ETC taught by Levine allows persons who have purchased 
the ETC to make cash withdrawals or cash transfers from 
automatic teller machines (ATM' s) or other cash-dispensing 
terminals (see Levine at the abstract and page 3 lines 2 to 11) . 
In a multicurrency environment, the ATM machine with which the 
ETC is being used sends the ETC's bank identification number and 
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a code indicating the currency of the ATM to a "VisaNet" 
computer. Thus, two different currencies may be involved, one 
for the ATM and another for the ETC. Levine 's VisaNet computer 
then provides any currency conversion needed (see Levine at page 
7, lines 29-33) . This is the opposite of what Appellant claims. 
A currency conversion is needed in Levine because the Levine 
transaction is performed exclusively using the ATM' s currency. 
Nothing in Levine teaches or suggests any feature that would 
allow the transaction to be performed using any other currency 
than that of the ATM (such as, Appellant's claimed preferred 
currency) . The Levine system does not associate the card 
currency with the transaction, i.e., change the currency of the 
transaction from the merchant currency to the cardholder 
currency at the point of sale. If Levine permitted the 
transaction to take place in the ETC's currency, then in 
contrast to the teaching of Levine, no currency conversion would 
need to take place. 

Again, within the context of a multicurrency environment of 
the present invention, for any individual merchant, individual 
transactions may take place using any one of a number of 
different currencies. That is, Appellant's claims define an 
invention that permits a payment card transaction to take place 
between a merchant and a customer using the customer's preferred 
currency. Like Boston, Levine does not disclose such a system. 
Rather, Levine discloses a system in which transactions take 
place exclusively in the currency of the merchant . 



Consequently, the teaching of Levine does not further the 
teaching of Boesch and/or Boston with respect to these features, 
as discussed above and claims 17-22 and 31-40 are believed to be 
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allowable. Accordingly, the Board is respectfully requested to 
reconsider claims 17-22 and 31-40. 



Conclusion 

Claims 1, 3-8, 10, 12-23, and 25-40 are included in this 
Appeal . 



The rejection of claims 1, 3, 10, 12, 23, and 25 under 35 
U.S.C. 102(e) as being anticipated by Boesch is believed to be 
improper. Likewise, the rejection of claims 4-8, 13-16, and 26- 
30 under 35 U.S.C. 103(a) as being unpatentable over Boesch in 
view of Boston is believed to be improper, and the rejection of 
claims 17-22 and 31-40 under 35 U.S.C. 103(a) as being 
unpatentable over Boesch and Boston in view of Levine is 
believed to be improper. In general, the references are silent 
as to any articulated or implied motivation for the 
modifications suggested in the Office Action. In addition, the 
references are silent as to all of the features of the claimed 
invention. However, a failure to teach or suggest all of the 
claimed features, lack of a suggestion for combination, and 
hindsight are improper standards for holding claims to be 
unpatentable . 
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Appellant believes that the arguments above fully respond to 
every outstanding ground of rejection and that the contested 
claims should be found allowable. 



Respectfully submitted, 




Attorney for Appellant 
Reg. No. 31,165 



Lowell W. Gresham 

5727 North Seventh Street 

Suite 409 

Phoenix, AZ 85014 
(602) 274-6996 
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Appendix A - - Claims on Appeal 



This Appendix is thirteen pages, including this cover page, 
and contains a clean double-spaced copy of the claims on appeal. 
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Claim 1 : A data processing method performed in a data 
processing system for determining a preferred currency for 
association with a payment card transaction between a merchant 
and a payment card cardholder, said method including the steps 
Of: 

obtaining the card number of the payment card; 

in said data processing system, identifying an identifier 
code from said card number; 

determining the operating currency for said identifier code 
by comparing said identifier code with entries in a table 
wherein each entry in said table contains an issuer identifier 
code or range of issuer identifier codes and a corresponding 
currency code; and 

setting the currency for association with the payment card 
transaction as the determined operating currency for the 
identifier code. 

Claim 3: A method according to claim 1, wherein the 
preferred currency is set to a default currency of the merchant 
when no operating currency can be determined for the identifier 
code . 

Claim 4: A method according to claim 1, wherein the 
cardholder is prompted as to whether the transaction is to be 
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conducted in the preferred currency, including the steps of 
converting the transaction amounts to equivalent amounts in the 
preferred currency and presenting these amounts for review by 
the cardholder. 

Claim 5: A method according to claim 1, wherein at least 
one of the transaction amounts is converted to an equivalent 
amount in the preferred currency and is presented to the 
cardholder. 

Claim 6: A method according to claim 5, further comprising 
the step of presenting an exchange rate to the cardholder, said 
exchange rate corresponding to a rate between the merchant's 
currency and the preferred currency. 

Claim 7: A method according to claim 5, wherein the 
transaction details in the merchant's currency are also 
presented to the cardholder. 

Claim 8: A method according to claim 1, further comprising 
the step of initially checking to determine if the transaction 
amount exceeds a predetermined minimum level for processing in 
an alternative currency to that of the merchant's currency. 
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Claim 10: A data processing system for determining a 
preferred currency for association with a payment card 
transaction, the payment card having a card number, between a 
merchant and a payment card cardholder, said means comprising; 

means for obtaining the card number of the payment card 
from the cardholder, 

means for identifying an identifier code from said card 
number, 

means for determining the operating currency for said 
identifier code by comparing said identifier code with entries 
in a table, wherein each entry in said table contains an issuer 
identifier code or range of issuer identifier codes and a 
corresponding currency code, and 

means for setting the currency for association with the 
payment card transaction as the determined operating currency 
for the identifier code. 

Claim 12: A data processing system according to claim 10, 
further comprising means for setting the preferred currency to 
the default currency of the merchant when no operating currency 
can be determined for the identifier code. 

Claim 13: A data processing system according to claim 10, 
further comprising prompting means for prompting the cardholder 
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as to whether the transaction is to be conducted in the 
preferred currency, said prompting means comprising conversion 
means for converting the transaction amounts to equivalent 
amounts in the preferred currency and presenting these amounts 
for review by the cardholder. 

Claim 14: A data processing system according to claim 13, 
further comprising means for accepting an indication from the 
cardholder as to whether the transaction is to proceed in the 
preferred currency and means for permitting the transaction to 
be processed in the preferred currency if such an indication is 
received. 

Claim 15: A data processing system according to claim 10, 
further comprising conversion means for converting at least one 
of the transaction amounts to an equivalent amount in the 
preferred currency and presenting this converted amount to the 
cardholder, optionally comprising means for presenting an 
exchange rate to the cardholder, said exchange rate 
corresponding to a rate between the merchant's currency and the 
preferred currency. 

Claim 16: A data processing system according to claim 10, 
further comprising means for initially checking to determine if 



APPELLANT'S BRIEF 
Serial No. 09/613,679 
Page A- 6 

the transaction amount exceeds a predetermined minimum level for 
processing in an alternative currency to that of the merchant's 
currency. 

Claim 17: A data processing system according to claim 10, 
wherein said data processing system is embodied in a payment 
card terminal . 

Claim 18: A data processing system according to claim 10, 
wherein said data processing system is embodied in a central 
payment router. 

Claim 19: A data processing system according to claim 10, 
wherein said data processing system is embodied in an 
authorisation host, optionally in co-operation with another 
system. 

Claim 20: A data processing system according to claim 19, 
wherein said other system is a payment card terminal or central 
payment router. 

Claim 21: A data processing system according to claim 10 
further comprising means for connecting to a node in a computer 
network. 
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Claim 22: A data processing system according to claim 21, 
wherein the card number is received via the computer network. 

Claim 23 : A computer program encoding a set of computer 
instructions for use in a computing device for determining a 
preferred currency for association with a payment card 
transaction, the payment card having a card number, between a 
merchant and a payment card cardholder, comprising 

a computer code section which when executed on the 
computing device obtains the card number of the payment card 
from the cardholder, 

a computer code section which when executed on the 
computing device identifies an identifier code from said card 
number, 

a computer code section which when executed on the 
computing device determines the operating currency for said 
identifier code, by comparing said identifier code with entries 
in a table, wherein each entry in said table contains an issuer 
identifier code or range of issuer identifier codes and a 
corresponding currency code, and 

a computer code section which when executed on the 
computing device sets the currency for association with the 
payment card transaction as the determined operating currency 
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for the identifier code. 

Claim 25: A computer program according to claim 23, 
comprising a computer code section which when executed on the 
computing device sets the preferred currency to the default 
currency of the merchant when no operating currency can be 
determined for the identifier code. 

Claim 26: A computer program according to claim 23, having 
a computer code section which when executed on the computing 
device prompts the cardholder as to whether the transaction is 
to be conducted in the preferred currency, including converting 
the transaction amounts to equivalent amounts in the preferred 
currency and presenting these amounts for review by the 
cardholder. 

Claim 27: A computer program according to claim 23, 
comprising a computer code section which when executed on the 
computing device converts at least one of the transaction 
amounts to an equivalent amount in the preferred currency and 
presents the converted amount to the cardholder. 

Claim 28: A computer program according to claim 27, 
comprising a code section which when executed on the computing 
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device presents an exchange rate to the cardholder, said 
exchange rate corresponding to a rate between the merchant's 
currency and the preferred currency. 

Claim 29: A computer program according to claim 27, 
comprising a computer code section which when executed on the 
computing device presents the transaction details in the 
merchant's currency to the cardholder. 

Claim 30: A computer program according to claim 23, 
comprising a code section which when executed on the computing 
device initially checks to determine if the transaction amount 
exceeds a predetermined minimum level for processing in an 
alternative currency to that of the merchant's currency. 

Claim 31: A method according to claim 1, wherein the card 
holder is prompted as to whether the transaction is to be 
conducted in the preferred currency, including the steps of 
converting the transaction amounts to equivalent amounts in the 
preferred currency and presenting an exchange rate to the 
cardholder, said exchange rate corresponding to a rate between 
the merchant's currency and the preferred currency. 



Claim 32: A method according to claim 1, wherein the card 
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holder is prompted as to whether the transaction is to be 
conducted in the preferred currency, including the steps of 
converting the transaction amounts to equivalent amounts in the 
preferred currency, presenting said equivalent amounts for 
review by the cardholder, and presenting an exchange rate to the 
cardholder, said exchange rate corresponding to a rate between 
the merchant's currency and the preferred currency. 

Claim 33: A data processing system according to claim 10, 
further comprising prompting means for prompting the cardholder 
as to whether the transaction is to be conducted in the 
preferred currency, said prompting means comprising means for 
presenting an exchange rate to the cardholder, said exchange 
rate corresponding to a rate between the merchant's currency and 
the preferred currency. 

Claim 34: A data processing system according to claim 10, 
further comprising prompting means for prompting the cardholder 
as to whether the transaction is to be conducted in the 
preferred currency, said prompting means comprising: 

conversion means for converting the transaction amounts to 
equivalent amounts in the preferred currency and presenting 
these amounts for review by the cardholder; and 

means for presenting an exchange rate to the cardholder, 
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said exchange rate corresponding to a rate between the 
merchant's currency and the preferred currency. 

Claim 35: A computer program according to claim 23, having 
a computer code section which when executed on the computing 
device prompts the cardholder as to whether the transaction is 
to be conducted in the preferred currency, including presenting 
an exchange rate to the cardholder, said exchange rate 
corresponding to a rate between the merchant's currency and the 
preferred currency. 

Claim 36: A computer program according to claim 23, having 
a computer code section which when executed on the computing 
device prompts the cardholder as to whether the transaction is 
to be conducted in the preferred currency, including converting 
the transaction amounts to equivalent amounts in the preferred 
currency, presenting these equivalent amounts for review by the 
cardholder and presenting an exchange rate corresponding to a 
rate between the merchant's currency and the preferred currency. 

Claim 37: A method of operating a data processing system 
to conduct a financial transaction for the exchange of money 
provided by a payment card cardholder for a good or service 
provided by a merchant, said method comprising: 
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obtaining a card number from said payment card; 

identifying, in said data processing system, an identifier 
code from said card number; 

determining an operating currency for said identifier code 
by comparing said identifier code with entries in a table that 
associates issuer identifier codes with currency codes; 

indicating said operating currency as being a preferred 
currency of exchange for said financial transaction; 

receiving a cardholder reply in response to said indicating 
activity; and 

completing said financial transaction in response to said 
receiving activity . 

Claim 38: A method as claimed in claim 37 wherein: 

said cardholder reply instructs said data processing system 

to conduct said financial transaction using said preferred 

currency; and 

said completing activity completes said financial 

transaction using said preferred currency. 

Claim 39: A method as claimed in claim 38 wherein: 

said indicating activity additionally indicates a currency 

exchange rate for converting from a merchant currency to said 

preferred currency; and 
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said completing activity uses said currency exchange rate 
in completing said financial transaction. 

Claim 40: A method as claimed in claim 38 wherein said 
indicating activity additionally indicates a first amount of 
money for said financial transaction using a merchant currency 
and a second amount of money for said financial transaction 
using said preferred currency. 
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Appendix B - - Evidence 



This Appendix is one hundred and sixty- five pages, 
including this cover page, and contains clean copies of all 
evidence (i.e., prior art references) under consideration. This 
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Description 

Technical Held 

The subject invention relates to a portable 
transaction card having an internal microprocessor. 
The subject card is capable of approving transac- 
tions in foreign currencies. 

Background of the Invention 

In recent years, there has been a strong trend 
towards a cashless society. To this end, large 
transaction card networks have been developed for 
purchasing goods and services. Along with wide- 
spread use of transaction cards there has also 
developed concurrent fraud losses. To combat 
these losses, a number of schemes have been 
implemented. The most common scheme is to 
print lists of cards which have been lost or stolen 
or whose holders have exceeded their assigned 
credit limits. When a card is presented during a 
transaction, the user's account number is com- 
pared with the circulated list to determine if the 
transaction should be authorized. This approach 
suffers from many drawbacks, not the least of 
which is the fact that the printed lists are always 
somewhat out of date. 

In order to overcome these shortcomings, a 
sophisticated network of on-line transaction termi- 
nals have been placed in merchant locations for 
authorizing transactions. In this system, the card 
number and transaction amount are entered into 
the terminal. The terminal then transmits that in- 
formation to the card issuer which determines if the 
transaction should be approved. The approval de- 
cision can be based on a number of factors. For 
example, the account number can be compared 
with a current list of lost or stolen cards. The 
transaction amount could also be compared to 
maximum transaction limit for that cardholder 
based on his credit worthiness or current deposits. 

While the above described on-line system is 
inherently more reliable than the distributed card 
list, it also has drawbacks. For example, the net- 
work requires numerous communication links which 
give rise to significant carrier costs. In addition, 
where large distances are involved, the response 
time can be less than satisfactory from both a 
customer and merchant standpoint. 

Various approaches have been implemented to 
reduce these problems. As described in U.S. Pat- 
ent No. 4,485,300, issued November 27, 1984 to 
Peirce, approval parameters supplied by the card 
issuer can be distributed to local area processors 
such that communication costs can be reduced. 
Another enhancement technique is described in the 
earlier European Patent Application No. 86 302 



120.0, publication no. 0 200 343, wherein approval 
information is stored on the card itself. This ap- 
proval information is stored and acted upon by the 
transaction terminal located at the merchant. In this 

5 manner, certain approvals can be completed in an 
off-line manner, that is, where there is no connec- 
tion to either the issuer or a central processor. The 
above cited patent and application are both as- 
signed to the assignee of the subject invention and 

10 the disclosures therein are incorporated by refer- 
ence. 

One method of implementing the off-line ap- 
proval system described in publication no. 0 200 
343, cited above is to encode the authorization 
75 data on a magnetic stripe formed on the card. 
More sophisticated off-line approval procedures 
can be performed where the transaction card is 
provided with an internal microprocessor and mem- 
ory. 

20 The first cards containing microprocessors, 
called smart cards, were developed approximately 
ten years ago and are used to a great extent in the 
European community. These cards typically in- 
clude electrical contacts to provide an interlace 

25 with a local transaction terminal. Information about 
the cardholder and associated transaction param- 
eters can be stored and updated inside the card. 
By reading this information the terminal can carry 
out an off-line authorization procedure. 

30 At the present time, smart cards are becoming 
very sophisticated, such that the authorization pro- 
cedure can be carried out in the card itself. For 
example the card can store a dollar amount which 
would represent the maximum amount of a transac- 

35 tion that could be authorized. During the transac- 
tion, the transaction amount could be entered into 
the smart card via the terminal. The microproces- 
sor in the card can then compare transaction 
amount with the stored transaction limit to deter- 

40 mine if the transaction should be approved. If the 
transaction is approved, an approval code would be 
generated and supplied to the customer and mer- 
chant. 

The use of smart cards can further reduce 
45 communication costs, time delays and fraud 
losses. Unfortunately, this approach is not geared 
towards international travel where one cardholder 
will be dealing with varying currencies. As can be 
appreciated, the transaction limit is stored in the 
so card in the form of a local or base currency, while 
purchases might be priced in a different, foreign 
currency. In this case, it would be impossible for 
the microprocessor in the card to make the com- 
parison necessary for authorization. Accordingly, it 
55 would be desirable to provide an improved transac- 
tion card which could operate with foreign cur- 
rencies. 

In the prior art, a number of devices have been 
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made which aid in currency conversion. For many 
years, mechanical, slide rule-type devices have 
been designed to aid the traveler in converting 
currency. More recently, a number of microproces- 
sor based devices have been developed for elec- 
tronically converting an amount from one currency 
to another. 

One example of a microprocessor driven cur- 
rency converter is disclosed in German application 
No. 3410065, laid open October 31, 1984. In this 
reference, it is suggested that a microprocessor- 
driven currency converter could be integrated in 
objects of frequent daily use, such as wrist watch- 
es. (See also German applications No. 2923478, 
laid open December 11. 1980, and No. 2905190, 
laid open August 21, 1980.) The above disclosures 
evidence the need of a traveler to easily convert 
currencies to facilitate a cash purchase. However, 
to date, this need has not been addressed for 
purchases made with a transaction card. More spe- 
cifically, no transaction card has been developed 
with the ability to convert a stored transaction limit 
to a foreign currency and then perform an internal 
authorization procedure. 

Accordingly, it is an object of the subject in- 
vention to provide a new and improved transaction 
card capable of authorizing a transaction in a for- 
eign currency. 

It is another object of the subject invention to 
provide a new and improved transaction card which 
includes a means for entering a conversion rate to 
permit the conversion of a stored transaction limit 
to a foreign currency. 

It is still another object of the subject invention 
to provide a new and improved transaction card 
which can be readily used in foreign countries. 

It is still a further object of the subject invention 
to provide a new and improved transaction card 
which can generate an approval of a transaction in 
a foreign currency without connection to a central 
processor. 

Summary of the Invention 

In accordance with these and many other ob- 
jects, the subject transaction card includes a stor- 
age means for holding a transaction limit repre- 
sented in a base currency, such as dollars. The 
storage means also holds rates for converting the 
base currency into different foreign currencies. A 
data entry means is provided for supplying the 
transaction limit and the conversion rates to the 
storage means. 

In accordance with the subject invention as 
disclosed in Claim 1, a processor means is con- 
nected to the data entry means and storage means 
and functions such that when a transaction is to be 
carried out in a currency other than the base cur- 



rency, the processor means will convert the trans- 
action limit stored in the base currency into the 
foreign currency using the associated conversion 
rate. Thereafter, the transaction amount expressed 

5 in the foreign currency and entered through the 
data entry means is compared to the converted 
transaction limit to determine if the transaction 
should be approved. 

It is believed that the smart cards presently 

jo available contain all of the hardware necessary to 
carry out the basic concept of the subject inven- 
tion. In the existing smart cards, the data entry 
means is defined by electronic contacts which in- 
terface with a transaction terminal. In the preferred 

75 and illustrated embodiment of the subject invention, 
the transaction card can carry out the authorization 
procedure independently of the terminal and is 
provided with its own data entry means, in the form 
of a key pad and an LCD display. 

20 In the preferred embodiment of the subject 
transaction card, the key pad is activated to select 
the currency used in the particular transaction. This 
selection will cause the microprocessor to convert 
the stored transaction limit to the selected cur- 

25 rency. The transaction amount is entered through 
the key pad and an approval code is generated 
internally and shown on the display means. This 
approval code can be noted on a sales draft for 
future reference. 

30 Further objects and advantages will be appar- 
ent from the following detailed description taken in 
conjunction with the drawings in which: 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 

Figure 1 is a plan view of a transaction card 
formed in accordance with the subject invention. 

Figure 2 is a schematic diagram illustrating the 
components of a transaction card of the subject 
40 invention. 

Figure 3 is a flow chart illustrating the steps 
taken to enter the currency conversion rates into a 
transaction card formed in accordance with the 
subject invention. 
45 Figure 4 is a flow chart illustrating the steps 

taken to select a foreign currency in accordance 
with the subject invention. 

Figure 5 is a flow chart illustrating the steps 
taken to carry out a transaction in a foreign cur- 
so rency in accordance with the subject invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

55 Referring to Figures 1 and 2, there is illustrated 
a transaction card having the elements necessary 
to carry out the objects of the subject invention. A 
more complete description of a card suitable for 
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this type of application can be found in the earlier 
European Patent Application No. 86 302 094.7, 
publication no. 0 203 683. 

As disclosed in the latter application, a signifi- 
cant body of published literature exists regarding 
the fabrication of microprocessor based transaction 
cards or smart cards. The objects of the subject 
invention can be obtained by modifying any of a 
number of the existing prior art smart cards. Ac- 
cordingly, the disclosure herein will be limited to a 
discussion of the modifications necessary to carry 
out the stated objects of the subject invention. 

As shown in Figure 2, the card 10 of the 
subject invention will include a microprocessor 20 
which is connected to storage means. In the illus- 
trated embodiment, the storage means is defined 
by a masked program ROM 22 and RAM 24. The 
masked program ROM 22, which is typically part of 
the microprocessor, will include the basic operating 
instructions of the transaction card. ROM 22 can 
also include default programs to allow the transac- 
tion card to operate in other modes, such as a 
conventional calculator. 

RAM space 24 is provided as temporary stor- 
age and to facilitate interfacing between the inputs 
of the key pad and electrical contacts. In the pre- 
ferred embodiment, additional storage in the form 
of an EEPROM 30 is provided for holding informa- 
tion, such as the transaction limit, discussed below, 
and one or more Personal Identification Numbers 
(PINS). 

In accordance with the subject invention, a 
means for entering data into the storage means 
must be provided. One suitable data entry means, 
illustrated in the drawings, includes a plurality of 
electrical contacts 28. The electrical contacts 28 
are intended to allow the card to interface with a 
transaction terminal located at a merchant. The 
contacts 28 can be used to both transmit and 
receive data and can also provide an independent 
power source for the operation of the smart card. 
At the present time, uniform standards are still 
being developed for electrical interfaces for smart 
cards. One suitable design can be found in U.S. 
Patent Number 4,222,516 to Badet. 

The hardware described above, modified in a 
manner discussed below, is sufficient to carry out 
the objects of the subject invention. In this configu- 
ration, the card could be operated only when con- 
nected to a transaction terminal. However, it is 
desirable that the card be capable of performing 
the authorization procedure independent of a trans- 
action terminal. 

In order to operate independently, a human 
operable data entry means must be provided. In 
the illustrated embodiment, the data input means is 
shown as a key pad 40. The key pad 40 is con- 
nected to the random access memory 24 through 



line 42 which is typically a plurality of strobe lines. 
The key pad includes a number of keys which 
allow the cardholder to select accounts, enter 
transaction amounts and scroll through displayed 

5 prompts, as discussed later in detail with regard to 
the operation of the card. 

Where the card is intended to operate indepen- 
dently of a terminal, it would also be desirable to 
provide a means for displaying human readable 

w output. In this case, the means is defined by an 
LCD display 50 driven by the microprocessor 20. 

A means for powering the card independent of 
the terminal should also be provided. This require- 
ment is satisfied in the subject invention through a 

75 battery 60. This battery may be recharged any 
time that the transaction card is used in conjunction 
with a transaction terminal. A panel of solar cells 62 
can be provided as an alternative source of energy. 
The solar cells 62 would be connected to a charger 

20 64 which, in turn, is connected to the battery 60. 

The card described above can be used to 
carry out the transactions in a manner similar to 
smart cards known in the prior art. For further 
information on smart cards see U.S. Patents 

25 3,971,916 to Moreno; No. 4,001,550 to Schatz; No. 
4,007,355 to Moreno; No. 4,092,524 to Moreno; No. 
4,102,493 to Moreno; No. 4,211,919 to Ugon; No. 
4,256,955 to Giraud; No. 4,295,041 to Ugon; No. 
4,417,413 to Hoppe; No. 4,443,049 to De Pommery 

30 and No. 4,447,716 to Aigo. 

In the illustrated embodiment, a transaction is 
initiated by pressing a key corresponding to the 
account which will be involved. The card can con- 
tain information regarding one or more accounts as 

35 indicated by keys 40A, B and C. Once the account 
is selected, a secret password or personal iden- 
tification number (PIN) must then be entered in 
order to continue the transaction. The amount of 
the transaction would then be entered through the 

40 numeric keys on the key pad 40. The microproces- 
sor will then evaluate the transaction for approval. If 
an approval can be given, an authorization code 
will be generated and shown on the display 50. 
Similar steps would be carried out if the card 

45 were connected to a local terminal. In this case, 
data would flow through contacts 28. The transac- 
tion amount could be entered into the key pad of 
the transaction terminal and then supplied to the 
card via contacts 28. The microprocessor in the 

so card would then evaluate the transaction and gen- 
erate either an approval or a denial which could be 
transmitted back to the terminal through contacts 
28. 

The authorization decision is made by the 
55 microprocessor by comparing the entered transac- 
tion amount with a transaction limit for the selected 
account stored in the card. The transaction limit is 
set by the issuer and can take a number of forms. 
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Where the account is for checking, savings or other 
similar types of accounts, the transaction limit will 
typically represent the amount which the customer 
has on deposit with the issuer. If the transaction 
amount does not exceed the stored transaction 
limit, the transaction can be approved. After the 
transaction is approved, the transaction limit is deb- 
ited by the amount of the transaction such that the 
transaction limit represents a declining balance for 
that account. 

The transaction limit can also be a fixed dollar 
level based upon the credit worthiness of the cus- 
tomer. For example, a certain customer may be 
assigned a transaction limit of $200. In this case, 
the card could approve any purchase which does 
not exceed $200. If the purchase exceeded $200, a 
more in depth analysis of the cardholder would be 
made by linking the card to the on-line approval 
network. 

In the transaction procedures described above, 
the microprocessor must compare the stored trans- 
action limit with the transaction amount. This com- 
parison is only possible where the two values are 
in the same currency. If the cardholder travels to a 
foreign country where the transaction amount is 
expressed in currency different from the local or 
base currency of the issuer, off-line approval would 
be impossible. This drawback is overcome in the 
subject invention as described in detail below. 

Briefly, the subject transaction card is provided 
with one or more rates for converting the base 
currency into different foreign currencies. The card- 
holder can then select the desired currency from 
the data input means. The microprocessor converts 
the transaction limit from the base currency to the 
selected foreign currency. Thereafter, when the 
transaction amount is entered, it can be directly 
compared with the converted transaction limit to 
permit the generation of an approval code. 

Figures 3 through 5 illustrate the operation of 
the device in greater detail. Figure 3 illustrates the 
steps carried out to enter the currency conversion 
rates into the card. As can be appreciated, because 
of the volatile nature of currency conversion rates, 
it would not be practical to issue a card with a fixed 
conversion rate. Therefore, it is envisioned that 
conversion rates will be entered into the card as 
needed. The conversion rates will be operable for a 
fixed period of time. 

It should be noted that the currency conversion 
rate does not have to be exact since it is not being 
used to reconcile the transaction. Stated differently, 
the rate is not used as the basis to transfer funds 
from the cardholder to the merchant. Rather, the 
rate is merely used to determine whether that 
particular cardholder should be authorized to com- 
plete the transaction. The evaluation of any card- 
holder is not particularly exact, and is based upon 



prior performance and statistical analysis. Thus, the 
transaction limit set by the bank is, to some extent, 
arbitrary. Thus, there is no need to insure that the 
conversion to a different currency is exact. Indeed, 

5 the card could be loaded with a conversion rate, 
intentionally weighted in favor of the issuer to re- 
duce potential losses. 

The first step in loading a conversion rate into 
the device requires the establishment of contact 

70 with the issuer as shown in block 102 in Figure 3. 
Where the card has been placed in a transaction 
terminal, such as, for example, an automatic teller 
machine (ATM), this link will be established via 
communication lines. If the transaction card itself is 

75 provided with human operable input and output 
means as shown in Figures 1 and 2, the link with 
the issuer could be established in person or 
through a normal telephone. In either case, the 
issuer must be supplied with the cardholder's 

20 name, the account number, the countries to which 
the cardholder, will be travelling and the travel 
dates as shown in block 104. 

Once supplied with this information, the issuer 
carries out the steps illustrated in block 106. The 

25 first step is to validate the identity of the cardholder 
based on the transmitted account number. The 
issuer will then generate a conversion rate and an 
associated expiration date. As noted above, the 
conversion rate does not have to be exact. The 

30 issuer will typically calculate a favorable rate which 
is unlikely to be reached in the given time period. If 
the time period stated by the cardholder is very 
long, an interim conversion rate can be generated 
and the cardholder would be requested to recon- 

35 tact the issuer for an update when the conversion 
rate expires. 

The conversion rate and the expiration date are 
then transmitted to the cardholder. In the preferred 
embodiment, some or all of this information is 

40 encrypted prior to transmission. The encryption 
scheme will be based on the account number and 
is designed to prevent a cardholder from entering a 
fraudulent rate. Where the card is being operated 
independently of a transaction terminal, the card- 

45 holder will enter the encrypted data corresponding 
to the conversion rate and the expiration date 
through the key pad 40. If the card is connected to 
a transaction terminal for this procedure, the trans- 
fer of data will take place automatically through 

50 contacts 28. In either case, conversion rates will be 
generated and supplied for each of the foreign 
currencies which are expected to be encountered. 
Once the loading of the conversion rates is com- 
plete, no further contact with the issuer is neces- 

55 sary. 

Turning to Figure 4, a flow diagram is provided 
illustrating the steps the cardholder takes upon 
entering a country where the currency is different 
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than the base currency of the issuer. As noted 
above, in existing cards, a transaction limit in the 
base currency (for example, dollars) will be stored 
in the memory 30 of the card. This transaction limit 
may be of the type which will be debited upon 
each purchase. In any case, in order to success- 
fully use the card in a foreign country, the cardhol- 
der must initiate a sequence for converting the 
stored transaction limit to the foreign currency. 

The first step in this procedure requires the 
cardholder to select the account which he intends 
to use. It should be noted that the transaction limit 
will most likely be different for each different ac- 
count, particularly in a situation where debiting of 
the transaction limit takes place after each pur- 
chase. However, only one conversion rate per cur- 
rency is necessary for each card. The account is 
selected by pressing one of keys 40A through 40C. 

When an account has been selected in step 
202, the microprocessor asks the cardholder pro- 
vide an unambiguous input of his identity. The 
most common form for this identification is through 
the use of a Personal Identification Number (PIN). 
The PIN is typically a multidigit number known only 
to the cardholder. The PIN is stored in a read only 
memory in the card and is compared with a num- 
ber entered by the cardholder at the time of the 
transaction. The use of a PIN prevents someone 
from utilizing a lost or stolen card. Preferably, a 
different PIN number is used for each account In 
the preferred embodiment, the transaction card 
stores the PIN in encrypted form and the card 
includes an algorithm to permit the cardholder to 
change his PIN. 

After the PIN has been entered and approved 
(block 204), the cardholder then selects the desired 
currency as shown in block 206. In the preferred 
embodiment, this step is performed in two parts 
through a scrolling technique. More particulary, 
after the PIN has been approved, one of a number 
of possible functions will be shown on the display 
means. These functions will include "MAKE A 
PURCHASE", "SEE AMOUNT AVAILABLE", "ADD 
TO ACCOUNT", "SELECT CURRENCY" etc. The 
particular prompt on the LCD display can be 
changed by pressing either the NEXT or BACK 
keys 40D and E, respectively. When the desired 
function is displayed, the YES key 40F is pressed. 
In this case, when the phrase "SELECT CUR- 
RENCY" is displayed, the YES key 40F is pressed, 
causing one of a list of currencies to be displayed. 

The currencies which would be displayed could 
include dollars, yens, francs, pounds, pesos, etc. 
Once again, the display can be scrolled using the 
NEXT and BACK keys 40D, E. The desired cur- 
rency is then selected using the YES button 40F. 
When this step has been completed, the micropro- 
cessor will then convert the transaction limit for the 



selected account from the base currency to the 
selected currency, using the associated conversion 
rate. During this process, the microprocessor will 
check to see that the expiration date associated 

5 with the current conversion rate is still in the future. 
This comparison requires that microprocessor in- 
clude a calender function. If the expiration date has 
passed, the conversion will not take place. 

The cardholder may verify that the conversion 

w has occurred by selecting from the menu the 
prompt "SEE AMOUNT AVAILABLE" (block 208). If 
the conversion has taken place, the transaction 
limit will be displayed in the selected currency. 
The currency can be changed again by the 

75 cardholder by the same process. In order to mini- 
mize the number of conversion rates stored in the 
card, the transaction limit should not be converted 
directly from one foreign currency to another for- 
eign currency. Rather, the microprocessor should 

20 first convert the selected foreign currency back to 
the base currency using the associated conversion 
rate and thereafter convert the base currency into 
the newly selected currency using the conversion 
rate associated with the newly selected currency. 

25 The cardholder can select the desired currency just 
prior to a purchase, however, it may be easier to 
select the currency at the time when the cardholder 
enters the foreign country. No further change is 
necessary until the cardholder leaves the country. 

30 Figure 5 illustrates the steps carried out when 
a purchase is to be made in a foreign currency 
after the transaction limit in the card has been 
converted to that selected currency. As in the pre- 
vious flow chart, the customer will first select the 

35 account to be used (block 302) by depressing any 
of the buttons 4A through C. The cardholder is then 
prompted with the request to enter his PIN (block 
304). Assuming the PIN has been entered and 
approved, the available options can then be ob- 

40 served by scrolling through the list using the NEXT 
and BACK keys 40D and E. When "MAKE A PUR- 
CHASE" is displayed, the user will press the YES 
button 40F as indicated by block 306. When this 
option has been selected, the user will be promp- 

45 ted by the display to enter the transaction amount. 
The cardholder enters the amount of the purchase 
in the selected currency using the numeric keys of 
pad 40 as indicated in block 308. 

Once the transaction amount has been entered, 

so the microprocessor will compare that amount to the 
transaction limit expressed in the foreign currency. 
If the transaction amount exceeds the transaction 
limit, no authorization will be generated and the 
transaction will be denied as shown in block 312. If, 

55 however, the transaction amount does not exceed 
the transaction limit, the microprocessor will gen- 
erate an approval code, as shown in step 314. 
In the illustrated embodiment, the approval 
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code will be shown on the display 50, as indicated 
in block 316. The displayed approval code is then 
entered into the sales draft by the merchant for 
future reference. For example, the presence of a 
proper approval code will generally free the mer- 
chant from liability from accepting a lost or stolen 
card. If the card is connected to a transaction 
terminal, the approval code might be shown on a 
display at the terminal or automatically imprinted 
directly on the sales draft. 

Where the particular account accessed is in 
the nature of a debit account and, if the transaction 
has been approved, the transaction limit will be 
debited by the amount of the transaction (block 
318). When the funds in the account have been 
exhausted, the cardholder must request an addi- 
tional amount from the issuer. This request proce- 
dure is performed in a manner analogous to the 
input of the conversion rates discussed above. 

In summary, there has been provided a new 
and improved transaction card which can be uti- 
lized to authorize transactions in a foreign cur- 
rency. This object is achieved by providing a 
means for converting a stored transaction limit to a 
selected currency. When the transaction amount is 
entered in the selected currency it can then be 
compared to the converted transaction limit to al- 
low the authorization process to proceed. 

Claims 

1. A transaction card for authorizing a transaction 
in foreign currencies comprising: 

data entry means (28, 40); 

storage means (24) for holding a transac- 
tion limit represented in a base currency and 
at least one rate for converting the base cur- 
rency to a different, foreign currency; and 

processor means (20) connected to the 
data entry means (28, 40) and the storage 
means (24) and functioning such that when a 
transaction is to be carried out in a foreign 
currency said processor means (20) will con- 
vert the transaction limit represented in the 
base currency into a transaction limit repre- 
sented in foreign currency using the asso- 
ciated conversion rate and thereafter compare 
the transaction amount expressed in the for- 
eign currency supplied through said data entry 
means (28, 40) to said converted transaction 
limit to determine if the transaction should be 
approved. 

2. A transaction card according to claim 1, 
characterised in that said processor means 
(20) generates an approval code if the transac- 
tion amount does not exceed the transaction 
limit. 



3. A transaction card according to claim 2, 
characterised by display means (50). 

4. A transaction card according to claim 3, 
5 characterised in that after said approval code 

is generated it is displayed on said display 
means (50). 

5. A transaction card according to claim 3, 
10 characterised in that said transaction amount is 

shown on said display means (50) after it has 
been entered. 

6. A transaction card according to claim 1, 
75 characterised in that if said transaction is ap- 
proved, said processor means (20) debits the 
transaction limit by the transaction amount. 

7. A transaction card according to claim 1, 
20 characterised in that said processor means 

(20) converts the transaction limit from one 
foreign currency to another by first converting 
said transaction limit into said base currency 
and thereafter into another foreign currency 
25 using the appropriate currency conversion 

rates. 

8. A transaction card according to claim 1, 
characterised in that an expiration date is 

30 stored in conjunction with each said conversion 
rate and in that said processor means (20) 
compares the expiration date with the current 
date to determine if the transaction should be 
authorized. 

35 

9. A transaction card according to claim 1, 
characterised in that the foreign currency is 
selected through said data entry means (28, 
40). 

40 

10. A transaction card according to claim 1, 
characterised in that said data entry means is 
defined by electrical contacts (28). 

45 11. A transaction card according to claim 1, 
characterised in that said data entry means is 
defined by a key pad (40). 

Patentanspriiche 

50 

1. Geschaftskarte zum Genehmigen eines Ge- 
schSfts in FremdwShrungen, mit: 
einer Dateneingabeeinrichtung (28, 40); 
einer Speichereinrichtung (24) zum Aufnehmen 
55 eines Geschaftslimits, das in einer Basiswah- 

rung dargestellt ist, und wenigstens eines Kur- 
ses zum Umrechnen der Basiswahrung in eine 
andere, fremde Wahrung; und 
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einer Prozessoreinrichtung (20), die mit der 
Dateneingabeeinrichtung (28, 40) und der 
Speichereiririchtung (24) verbunden ist und so 
funktioniert, dafi, wenn ein Geschaft in einer 
Fremdwahrung auszufuhren ist, die Prozessor- 
einrichtung (20) das Geschaftslimit, das in der 
Basiswahrung dargestellt wird, in ein Ge- 
schaftslimit, das in der Fremdwahrung darge- 
stellt wird, unter Verwendung des zugeordne- 
ten Umrechnungskurses umrechenen und an- 
schlieBend den in der Fremdwahrung ausge- 
drUckten Geschaftsbetrag, der uber die Daten- 
eingabeeinrichtung (28, 40) eingegeben wird, 
mit dem umgerechneten Geschaftslimit ver- 
gleichen wird, um festzustellen, ob das Ge- 
schaft genehmigt werden sollte. 

2. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, daB die Prozessoreinrichtung 
(20) einen Genehmigungscode erzeugt, wenn 
der Geschaftsbetrag das Geschaftslimit nicht 
ubersteigt 

3. Geschaftskarte nach Anspruch 2, gekennzeich- 
net durch ein Anzeigeeinrichtung (50). 

4. Geschaftskarte nach Anspruch 3, dadurch ge- 
kennzeichnet, datf, nachdem der Genehmi- 
gungscode erzeugt worden ist, er auf der An- 
zeigeeinrichtung (50) angezeigt wird. 

5. Geschaftskarte nach Anspruch 3, dadurch ge- 
kennzeichnet, dafl der Geschaftsbetrag auf der 
Anzeigeeinrichtung (50) angezeigt wird, nach- 
dem er eingegeben worden ist. 

6. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, daJ3, wenn das Geschaft geneh- 
migt ist, die Prozessoreinrichtung (20) das Ge- 
schaftslimit mit dem Geschaftsbetrag belastet. 

7. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, daB die Prozessoreinrichtung 
(20) das Geschaftslimit aus einer Fremdwah- 
rung in eine andere umrechnet, indem sie zu- 
erst das Geschaftslimit in die Basiswahrung 
und anschlieflend in eine andere Fremdwah- 
rung unter Verwendung der geeigneten Wah- 
rungsumrechnungskurse umrechnet. 

8. Geschaftskarte nach Anspruch 1. dadurch ge- 
kennzeichnet, dafi ein Ablaufdatum in Verbin- 
dung mit jedem der Umrechnungskurse ge- 
speichert wird und daJ3 die Prozessoreinrich- 
tung (20) das Ablaufdatum mit dem laufenden 
Datum vergleicht, um festzustellen, ob das Ge- 
schaft genehmigt werden sollte. 



9. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, dafl die Fremdwahrung Uber die 
Dateneingabeeinrichtung (28, 40) ausgewahlt 
wird. 

5 

10. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, dafl die Dateneingabeeinrichtung 
durch elektrische Kontakte (28) gebildet ist. 

w 11. Gescha'ftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, da/3 die Dateneingabeeinrichtung 
durch eine Tastatur (40) gebildet ist. 

Revendlcatlons 

75 

1. Carte de transaction pour autoriser une tran- 
saction dans des monnaies 6trangeres com- 
prenant : 

- des moyens d'entree de donnees (28, 
20 40); 

- un moyen de stockage (24) pour le main- 
tien d'une limite de transaction represen- 
tee par une monnaie de base et au 
moins un taux de conversion de la mon- 

25 naie de base en une monnaie Etrangere 

differente et 

- un moyen de processeur (20) raccorde 
aux moyens d'entree de donnees (28, 
40) et aux moyens de stockage (24) et 

30 fonctionnant de telle fagon que lors- 

qu'une transaction doit etre rdalis^e en 
une monnaie etrangere, ledit moyen de 
processeur (20) convertisse la limite de 
transaction representee par la monnaie 

35 de base en une limite de transaction 

representee par la monnaie etrangere a 
Taide du taux de conversion associe puis 
compare le montant de la transaction ex- 
prime dans la monnaie etrangere fournie 

40 via lesdits moyens d'entree de donnees 

(28, 40) a ladite limite de transaction 
convertie pour determiner si la transac- 
tion doit etre acceptee. 

45 2. Carte de transaction selon la revendication 1, 
caract6ris6e en ce que ledit moyen de proces- 
seur (20) genere un code d'acceptation si le 
montant de la transaction n'exc£de pas la limi- 
te de transaction. 

50 

3. Carte de transaction selon la revendication 2, 
caract6ris6e par un moyen d'affichage (50). 

4. Carte de transaction selon la revendication 3, 
55 caracterisee en ce que, apres la generation 

dudit code d'acceptation, il est affiche sur ledit 
moyen d'affichage (50). 
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5. Carte de transaction selon la revendication 3, 
caracterisee en ce que ladite quantite de tran- 
saction est visualised sur ledit moyen d'afficha- 
ge (50) apres son entree. 

5 

6. Carte de transaction selon la revendication 1, 
caracterisee en ce que, si ladite transaction est 
accepted, ledit moyen de processeur (20) 66- 
bite la limite de transaction de la quantite de la 
transaction. 10 

7. Carte de transaction selon la revendication 1, 
caracteVise* en ce que ledit moyen de proces- 
seur (20) convertit la limite de transaction 
d'une monnaie etrangere en une autre par une 15 
premiere conversion de ladite limite de tran- 
saction en ladite monnaie de base puis en une 
autre monnaie etrangere k I'aide des taux ap- 
propries de change de monnaie. 

20 

8. Carte de transaction selon la revendication 1, 
caracterisee en ce qu'une date d'expiration est 
stocked en conjonction avec chacun desdits 
taux de conversion et en ce que ledit moyen 

de processeur (20) compare la date d'expira- 25 
tion avec la date courante pour determiner si la 
transaction doit etre accepted. 

9. Carte de transaction selon la revendication 1, 
caracterisee en ce que la monnaie etrangere 30 
est choisie via lesdits moyens ddntred de don- 
neds (28, 40). 

10. Carte de transaction selon la revendication 1, 
caracteVised en ce que lesdits moyens d'en- 35 
tree de donneds sont definis par des contacts 
eMectriques (28). 

11. Carte de transaction selon la revendication 1, 
caracterisee en ce que lesdits moyens d'en- 40 
tree de donneds sont definis par un pave nu- 
merique (40). 
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by the customer. The central card processor 
(66) establishes a zero balance database includ- 
ing the card numbers (17), but with blank fields 
for the customer data and the value of the ac- 
count (78). When a customer purchases a card, 
the sales agent (40) transmits to the central data- 
base computer (45) which tills in the blanks in 
the database (46), activating the account, and 
transmits an acknowledgement The card can be 
immediately used in ATM (50) or other remote 
terminals to acquire cash or purchase goods and 
services. The customer inputs a PIN number 
which is provided with the card, or an alterna- 
tive PIN number selected by the customer. 
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A METHOD AND APPARATUS FOR DISTRIBUTING CURRENCY 

BACKGROUND OF THE INVENTION 
The present invention relates to systems and 
processes for dispensing currency to a cardholder in response 
to an authorization over an electronic data network. 

A variety of. cards are available to enable a 
customer to electronically interface with a financial 
institution. Credit cards are a well-known example of this, 
plastic cards having a magnetic stripe with an encoded account 
number. These cards can be read by special terminals at a 
merchant's site, commonly referred to as point-of-sale (POS) 
terminals. The account number can then be transmitted over a 
network, such as the VisaNet network. In addition to the 
account number, the amount of the transaction is also 
transmitted for authorization. A remote main-frame computer 
checks a database to determine if the credit card customer is 
still within his/her credit limit, before authorizing the 
purchase . 

Another type of card is a debit card, which is not 
used to extend credit, but rather to withdraw cash or pay a 
merchant immediately. The amount of the transaction is 
deducted from the customer's checking account, which the 
customer can periodically replenish. Here, the customer must 
have the money in the account before the transaction is 
approved, rather than having to pay the money on credit 
extended, as for a standard credit card. 

Another type of card is an automated teller machine 
(ATM) card. These are typically issued by a particular 
financial institution or bank, allowing a customer to access 
the customer's checking or savings account for withdrawal from 
a remote ATM. The remote ATM is connected through an ATM 
interchange to various banks subscribing to a particular ATM 
network. Like a debit card, this card causes an immediate 
deduction from the customer's account. The immediate 
deduction is actually a same day or same night deduction, 
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since the amount of the transaction is typically recorded, and 
then actually processed in batch mode at night with other 
transactions. One danger of the ATM system is that of a lost 
or stolen card. The use of a Personal Identification Number 
5 (PIN) , known only to the customer, eliminates much of the 
risk. Another control is imposing a daily limit, $200, for 
instance, on any withdrawals by a particular card during any 
day. 

Other types of cards store the account amount 

10 directly on the card. An example would be a transit card, 

such as cards for the Bay Area Rapid Transit (BART) District. 
When these cards are purchased, the dollar amount of the card 
is magnetically recorded on the card. Each time the card is 
used by passing it through an access terminal, the fare is 

15 deducted from the amount on the card, and a new card value is 
magnetically recorded on the card itself. An advantage of 
such a card is that if it is lost or stolen, the potential 
loss value is only the amount recorded on the card itself. A 
disadvantage is that there is no ability to contact the issuer 

20 and freeze the remaining account balance. 

Other than these different types of cards, and 
currency itself, there is yet another device for obtaining 
cash which is very popular. That is the paper travellers 
cheque. Travellers cheques are desirable as compared to 

25 currency because of the signature authorization required and 

the ability to report them as stolen or lost and identify them 
by serial number. In addition, they are issued in limited 
amounts, and thus may limit the possible exposure. Unlike 
debit cards or credit cards or even ATM cards, there is no 

30 account number which can easily be verified online to see if 
the account has been closed. 

SUMMARY OF THE INVENTION 
The present invention provides an electronic cash 
35 access process which includes a unique combination of aspects 
of both debit cards and travellers cheques, referred to herein 
as an Electronic Travellers Cheque (ETC) . The process can 
also be used for money transfer and any other pre-paid cash 
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access product. A card is issued to a customer with a value 
selected by the customer. Unlike a credit or debit card, the 
value is fixed. Unlike a transit card, the amount of the 
value of the card is stored in a central computer. The card 
can be used to access the account through an ATM or other 
terminals world-wide, with the use of a personal 
identification number (PIN) to provide added security greater 
than that, for instance, given by the signature on a 
traditional paper travellers cheque. The card is disposable 
when the account is depleted, with a new card and account 
required for a new amount of cash. 

The cards themselves have a magnetic stripe with an 
encoded card number including a bank identification number 
(BIN) and an account number. The cards may be issued by 
multiple ETC issuers who have financial responsibility for the 
accounts, but are processed on their behalf by a single entity 
referred to as the ETC processor herein. The ETC processor 
establishes a zero balance database including the card 
numbers, but with blank fields for the customer data (name, 
address, etc.) and the value of the card. The cards are 
provided to a bank or other sales agent. When a customer 
purchases a card, the sales agent uses local software to 
remotely transmit to the central database the card number (or 
a serial number) along with the customer data and the amount 
purchased. The software at the ETC processor fills in the 
blanks in the database, activating the account, and transmits 
an acknowledgement signal back to the sales agent software. 

The customer can immediately use the card in ATM or 
other remote terminals to acquire cash or purchase goods or 
services. The customer inputs a PIN number which is provided 
with the card, or a customer selected alternative PIN number. 
The transaction is handled by the ATM or other terminal in 
much the same manner as a normal ATM transaction using an ATM 
card. 

When the cards are manufactured, they preferably 
have a serial number printed on them which is different from 
the card number recorded on a magnetic stripe on the card. 
The sales agent would actually preferably transmit the serial 
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number over the data link to the ETC processor for added 
security. In addition, the agent will transmit an agent 
identification number. The ETC processor verifies that the 
agent is authorized to sell a particular serial number, and 
5 translates the serial number into the appropriate card number, 
including the BIN number and account number. The remote 
computer can then determine a location in the database to be 
loaded with the account information. 

The BIN number of the issuing institution is stored 

10 in the database in the ETC processor along with an indication 
of the currency used for issuance. A particular bank may have 
multiple BIN numbers for multiple types of currencies in which 
cards can be issued. When a customer uses the card in a 
remote terminal, that terminal may be connected to an 

15 intermediate network, such as the VisaNet network. The 

currency of the terminal is transmitted to the central VisaNet 
computer, and the central VisaNet computer does a currency 
conversion, if necessary, to debit the account balance. 

The serial number provides an additional level of 

20 security. The sales agent can transmit the serial number, 

making it more difficult for someone to intercept the message 
and determine the account number. Also, a customer can select 
or change the PIN from any touch tone phone by using the 
serial number printed on the card. In addition, the central 

25 database has fields for storing status information indicating 
that certain serial number cards have been ordered from the 
manufacturer, shipped to the sales agent, and received by the 
sales agent. This information can be accessed by standard 
inventory software to track it and keep it current for 

30 security to insure an agent is authorized to sell a particular 
serial number card. 

For a fuller understanding of the nature and 
advantages of the invention, reference should be made to the 
ensuing detailed description taken in conjunction with the 

35 accompanying drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a diagram of an ETC card according to the 
present invention; 

Fig. 2 is a diagram illustrating the production of 
5 the card of Fig. 1; 

Fig. 3 is a simplified block diagram illustrating 
the issuance and use of the electronic travellers cheque (ETC) 
of the present invention; 

Fig. 4 is a block diagram of the data network used 
10 by the present invention; 

Fig. 5 is a flowchart illustrating the program steps 
for issuance and activation of an ETC; 

Fig. 6 is a flowchart illustrating a software 
program. for controlling the usage of an ETC; 
15 Fig. 7 is a flowchart illustrating a software 

program for controlling replacement card issuance; and 

Fig. 8 is a flowchart illustrating a program for 
assigning a replacement PIN. 



20 DESCRIPTION OF THE PREFERRED EMBODIMENT 

Fig. 1 is a diagram of an ETC card 10 according to 
the present invention. The card has a magnetic stripe 12 on 
it, including the account information. The magnetic stripe 
has encoded on it first a bank identification number (BIN) 14. 

25 This number not only defines the issuing bank, but also the 

currency in which the card was issued. If a bank issues only 
in U.S. currency, it might have just a single number, while a 
bank which issues in multiple currencies might have multiple 
BIN numbers assigned. A second number is the actual account 

30 number 16 for the particular card. The BIN and account number 
form a card number 17, sometimes also referred to as a Primary 
Account Number (PAN) . A third number is a service code number 
18 which identifies to the appropriate software that this is a 
"cash only" use card. An alternate service code could be used 
* 35 for authorizing the card for debits for a purchase at a 

merchants site in a point of sale (POS) device. Finally, a 
Card Verification Value (CW) 19 is used for error detection 
and fraud detection. 
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The card also includes a serial number 20 printed on 
the face of the card to be visible to a sales agent. The 
serial number can be related by the computer to the encoded 
account number, which is not itself visible. Finally, a memo 
5 pad 22 is included on the card, with multiple lines for a 
customer to write on to indicate the current balance on the 
card. As each withdrawal is made with the card, the customer 
can indicate the remaining balance by subtracting the amount 
withdrawn from the previous balance and writing it on the 

10 card. The card is not embossed to prevent its use as a credit 
or debit card. Fraud possibilities are thus limited because 
it cannot be used to produce imprints like a credit card or 
debit card. There is no need for an expiration date as for a 
credit card since there is no need for credit controls because 

15 the money has already been received by the issuer. However, 
an expiration date (which may be a long time in the future) 
may be encoded on the magnetic stripe so it will be compatible 
with ATM and other terminals that expect to see an expiration 
date to accept a card. 

20 Fig. 2 is a diagram illustrating the actual creation 

of the cards. A series of blank cards 26 are provided to card 
personalizing machinery 28. Machinery 28 encodes on the 
magnetic stripe on the card the card number (the BIN number 
and the account number) f the service code and the CW number. 

25 In addition, the serial number is printed on the card, with 

the finalized card 10 coming out of the output of the machine. 
At the same time, a printed envelope or jacket 30 is produced 
from a printer 32. The envelope 30 will include in it a 
personal identification number (PIN) . The card is placed in 

30 its corresponding envelope to produce a combined media and pin 
jacket 34. A record of the BIN, account and other numbers is 
stored in an issuer record database 36. A number of card 
packages 34 can be provided for the inventory of a particular 
sales agent for sales to end customers. 

35 Fig. 3 is a diagram illustrating the activation and 

use of the ETC cards at a broad level. A sales agent 40 has a 
stack of packaged cards 34 in inventory. A customer 42 can 
approach the sales agent, indicating the customer's name and 
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other identifying information, along with the amount of value 
desired. The sales agent selects an ETC card and enters its 
serial number into a terminal (which could be a telephone) 44, 
along with the customer data and amount. The terminal then 
5 transmits this information via communications link 43 to a 
network such as the VisaNet network 51 (as used herein, 
VisaNet network refers to the combination of the hardware, 
software and other elements which comprise the network) . The 
sales agent will also transmit a sales agent code and 

10 password. The sales agent code will identify the agent or 
financial institution. If the sales agent is authorized to 
issue multiple currencies, a code for the appropriate currency 
desired by the customer is used. 

A database 4 6 in a main-frame computer 45 looks up 

15 the BIN and then the account number for that serial number in 
a database 46. The database will include blanks for the 
customer data and amount next to each account number, which 
will be filled in by the information provided. The computer 
will then send an acknowledgement message back to the sales 

20 agent, who will print a receipt for the customer and complete 
the transaction. 

The customer can then go to any Visa ATM 50 to use 
the card. ATM 50 is connected to the VisaNet network via 
communications link 52. The data transmitted by the ATM 

25 includes the card number and the amount of the currency the 

customer wishes to withdraw. This currency amount is compared 
to the amount stored in the database for that card number. If 
sufficient value is authorized, the withdrawal is authorized 
by return message. The VisaNet computer provides any currency 

30 conversion needed, since the ATM will transmit a code 

indicating the currency it dispenses and the database will 
know the currency of the card from the BIN number for that 
card number stored in its database. 

The account number for the ETC card is not an 

35 account of the sales agent or bank. Instead, it is an account 
maintained with the ETC issuer. Thus, no preexisting account 
relationship with the bank or sales agent is required. In 
addition, the issuing procedure for the ETC card results in 
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instant activation of the account and the card. The customer 
can literally walk to a Visa ATM outside the bank issuing the 
card and use the ETC card immediately. 

Fig. 4 is a more detailed block diagram of an 
5 electronic network used by the present invention. A first 
sales terminal 60 is shown connected through an interface 62 
to a communication line, such as a digital T-l line 64 to an 
ETC processor 66. A second sales terminal 68 at a separate 
bank or sales agent is connected through a dial-up modem 70 to 

10 a public packet-switched network communication link 72 to ETC 
processor 66. The ETC processor includes a computer 74 
connected to an inventory database 76, an account database 78, 
and an agent database 80. The account database 78 stores the 
account information which is updated each time a customer uses 

15 the ETC card. 

ETC processor 66 is connected to a network, such as 
VisaNet network 82. VisaNet network 82 includes a central 
computer with a communication processor 84, such as an IBM 
3745. The communication processor 84 is connected to a main- 

20 frame 86, such as an IBM 3090. A memory 88 provides storage 
for main-frame 86. A control terminal 90 allows for local 
servicing and control. 

Communication processor 84 is connected to an ATM 
interchange 92, which in turn is connected to individual ATM 

25 machines 94. In addition, the communication processor 84 may 
be connected to a direct-debit network 96, which is connected 
to individual point-of-sale (POS) terminals 98. 

In operation, when a card is used at an ATM 94, a 
message is passed through ATM interchange 92 to VisaNet 

30 network 82. The VisaNet network determines the destination, 
then forwards the message to the ETC processor for 
authorization and debiting of the account balance. The return 
message is passed from ETC processor 66, through VisaNet 
network 82 and ATM interchange 92 to the individual ATM 

35 machine 94, which can now dispense cash to the customer. 

Another VisaNet service is stand-in processing 
(STIP) software 100, typically used when a connected processor 
is not available. This STIP software includes positive 
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cardholder authorization service (PCAS) software which can do 
card number verification, PIN verification, and balance 
verification, if desired. 

Fig. 5 is a flowchart illustrating the operation of 
5 the software at the sales agent's terminal in conjunction with 
the software at the ETC processor. The sales agent first 
inputs an agent number and an agent password (step A) . Next, 
the card serial number is input (step B) . The customer data 
and the currency amount are also input (steps C and D) . 

10 Finally, the customer may optionally select a PIN number other 
than the one preassigned, if the sales agent has this 
capability (step E) . Alternately, the customer may change the 
PIN at a touch-tone phone as shown in Fig. 8, discussed below. 
This information is then transmitted to the ETC processor via 

15 the datalink (step F) . 

The software at the ETC processor, upon receiving 
the transmitted data, first validates the agent number and 
password by comparing it to the database 80, shown in Fig. 4, 
of authorized agents and passwords (step G) . A translation 

20 table is then consulted to determine the card number from the 
serial number (step H) . The card number is used to find the 
appropriate BIN and account number records in the database 
(step I) . 

The account database is consulted, looking up the 
25 entries corresponding to that issuer BIN (step J) . Once that 
sector of the database is located, the particular account 
number is located (step K) . The inventory status data stored 
with the account number is checked to determine if the serial 
number received was distributed to that sales agent. The 
30 customer data and currency amount is then entered into the 
blank fields corresponding to that account number in the 
database (step L) . The account number and the PIN number 
stored in the database (or a new PIN number transmitted by the 
customer) are then transmitted to the VisaNet system for 
35 updating of the PCAS software (step M) . Finally, an 

acknowledgement message is sent back to the sales agent (step 
N). 
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The software at the ETC processor also calculates an 
agent commission, if any (step O) . This is stored in the 
database, with a settlement routine (step P) being run at the 
end of the day. Finally, back at the agent terminal, the 
agent terminal software, upon receipt of the acknowledgement 
message from the ETC processor, prints a customer receipt 
(step Q) . 

The use of a serial number separate from the card 
number allows a customer to securely use a touch-tone phone to 
change a PIN by transmitting the identifying serial number. 
A customer can access customer service software through a 
touch-tone phone for this purpose. The customer could also be 
required to transmit other customer data, to enable a check of 
the database to confirm that customer data is associated with 
that serial number or corresponding card number. 

The status data maintained in the account database 
allows additional security for card inventory, in one 
embodiment, a first status field is used to indicate when the 
issuer has placed an order with the card manufacturer to 
create more cards. A second status field indicates an 
acknowledgement from the card manufacturer that the cards have 
been made and shipped to a particular sales agent. A third 
status field is used to indicate an acknowledgement from that 
sales agent of receipt of the cards. Thus, a multiple point 
check is built into the database. Using the account database 
to store this inventory information also allows simple 
inventory software to be used, and integrates the inventory 
security requirements (unique to this type of a card) with the 
rest of the system. 

Fig. 6 is a flowchart illustrating the software used 
when a customer actually uses the card after issuance. The 
customer can insert the card into a standard Visa ATM machine 
(alternately, a POS or other device may be used) . The ATM 
machine software causes the magnetic stripe to be read and 
determines the card number, including the BIN number and 
account number from the card (step A). The customer then 
inputs the PIN number, which the software also captures (step 
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B) . Finally, the customer inputs the desired debit amount to 
be withdrawn (step B) . 

The local ATM software then transmits a message to 
the VisaNet system with the input information (step C) . The 
ATM also transmits a currency code which shows what currency 
is in the ATM. The VisaNet network performs any required 
currency translation (step D) • The ETC processor software 
then looks up the card number in the database (step E) , and 
the PIN number associated with the account in the database is 
compared to the transmitted PIN number (step F) • If the PINs 
don f t match, a return error message is transmitted to the ATM 
(step G) . 

If the numbers do match, the debit amount is then 
compared to the amount remaining in the account (step H) . If 
there is insufficient funds, an error message is returned to 
the ATM indicating insufficient funds (step I) . If sufficient 
funds are available, the software then updates the balance for 
that account after the debit (step J) , and an authorization 
approval message is returned to the ATM (step K) . 

Fig. 7 illustrates a software routine used by a 
service center to issue a new card when a customer has lost 
the card. The service agent first inputs the customer name 
and other data along with a new account number corresponding 
to a new card, just as in the new card routine (step A) . This 
is transmitted to the ETC processor, which then does a lookup 
of the account, matching the customer name and other data to 
verify ownership of the account. If the card number or card 
serial number are available, these can be used instead (step 

B) . If there is no match, an error message is returned (step 

C) . 

If the customer name and other data matches to 
verify account ownership, the old account is closed (step D) . 
The amount of the old balance is then transferred to the new 
account, along with the customer name and any other 
identifying information (step E) . An acknowledgement message 
is then transmitted back to the service agent (step F) . The 
other aspects of the card issuance set forth in Fig. 5 are 
also followed, with Fig. 7 setting out the new steps required 
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for transfer from one account to another. As can be seen, a 
lost card can thus have the account closed, rendering it 
useless. This is an advantage over a paper travellers cheque, 
which could be forged. 
5 Fig. 8 illustrates the operation of the service 

agent software for assigning a new PIN number where a customer 
desires a new PIN or has forgotten the PIN number. The 
service agent first inputs the customer name and any other 
identifying data that is available, along with the desired new 

10 PIN number (step A) . The old PIN could also be required, 

except for a lost PIN. This information is then transmitted 
to the ETC processor computer (step B) . The ETC processor 
computer compares the account information to determine whether 
there is sufficient information to claim that account (step 

15 C) . If there is insufficient or non-matching information, an 
error message is returned (step D) . 

Otherwise, the PIN number assigned to that account 
is updated (step E) . The new PIN number is also transmitted 
to the PCAS issuer record database in the VisaNet system for 

20 updating as well (step F) . Finally, an acknowledgement 

message is returned to the service agents software (step G) . 

As will be understood by those familiar with the 
art, the present invention may be embodied in other specific 
forms without departing from the spirit or essential 

25 characteristics thereof. Accordingly, the disclosure of the 
preferred embodiment of the invention is intended to be 
illustrative, but not limiting, of the scope of the invention 
which is set forth in the following claims. 
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WHAT IS CIAIMED IS ; 

1. A method for distributing currency or purchasing 
goods and services, comprising the following steps: 

generating a plurality of card numbers, each card 
number including an account number and a bank 
identification number, corresponding to card numbers 
encoded on a plurality of cards; 

creating a database on a central computer having at 
least a first field for said bank identification number, 
a second field for said account number, a third field for 
customer data, a fourth field for a currency amount, and 
a fifth field for a personal identification number (PIN) ; 

loading said bank identification number and said 
account numbers into said database, leaving said third 
and fourth fields blank; 

receiving, at the time of card purchase, customer 
data, an ID number corresponding to a card number and a 
currency amount selected by a customer from a first 
remote terminal; 

immediately entering said customer data and said 
currency amount into said third and fourth fields, 
respectively, of said database corresponding to a bank 
identification number and an account number included in 
said card number; 

immediately entering a personal identification 
number (PIN) into a fifth field of said database 
corresponding to said customer; 

subsequently receiving, from a second remote 
terminal, a customer inputted PIN, a card number from a 
card for said customer and a debit currency amount; 

subtracting said currency debit amount from the 
currency amount in said database corresponding to the 
received customer card number and PIN and updating said 
currency amount in said database; 

transmitting to said second remote terminal an 
authorization message for dispensing said currency debit 
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amount to the customer if said currency debit amount is 
not greater than said currency amount in the database; 

transmitting to said second remote terminal a 
message denying the dispensing of currency if said 
5 currency debit amount is greater than the currency amount 

in the database • 

2. The method of claim 1 further comprising the 

steps of: 

transmitting, from said second remote terminal, a 
currency code indicating a currency type in said second 
remote terminal; 

comparing said currency type to an issuance currency 
of said card indicated by said bank identification 
number ; and 

converting said debit currency amount of said 
currency type to said issuance currency. 

3. The method of claim 1 further comprising the 

steps of: 

printing a serial number different from said card 
number on each of said cards; 

transmitting said serial number as said ID number; 

and 

converting said serial number into said card number. 

4. The method of claim 1 further comprising the 

steps of: 

storing inventory control status information in said 
database to indicate the status of said cards; 

receiving a sales agent ID with said ID number for 
said card; 

comparing said sales agent ID with said inventory 
control status information; 

returning an error message if said comparing step 
does not produce a match • 
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5* The method of claim 4 wherein said inventory 
control status information includes first data indicating the 
ordering of cards by an issuer, second data indicating the 
shipment of cards by a card manufacturer and third data 
indicating the receipt of cards by said sales agent. 

6. The method of claim 1 further comprising 
changing said PIN according to the steps of: 

receiving a new PIN and said ID number; 

locating a card number corresponding to said ID 
number in said database; and 

replacing the PIN in said fifth field for said card 
number with said new PIN. 

7. A method for distributing currency or purchasing 
goods and services, comprising the following steps: 

generating a plurality of card numbers, each card 
number including an account number and a bank 
identification number, corresponding to card numbers 
encoded on magnetic stripes on a plurality of cards; 

printing a visible serial number, different from, 
but related to, said card number, on each of said cards; 

creating a database on a central computer having at 
least a first field for said bank identification number, 
a second field for said account numbers, a third field 
for customer data, and a fourth field for a currency 
amount ; 

loading said bank identification number and said 
account numbers into said database, leaving said third 
and fourth fields blank; 

storing inventory control status information in said 
database to indicate the status of said cards; 

receiving customer data, the serial number and a 
currency amount from a first remote terminal; 

receiving a sales agent ID with said serial number 
for said card; 

immediately translating said serial number into a 
card number; 
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immediately entering said customer data and said 
currency amounts into said third and fourth fields, 
respectively, of said database corresponding to a bank 
identification number and an account number included in 
said card number; 

immediately entering a personal identification 
number (PIN) into a fifth field of said database 
corresponding to said customer; 

comparing said sales agent ID with said inventory 
control status information; 

returning an error message if said comparing step 
does not produce a match; 

subsequently receiving, from a second remote 
terminal, a customer inputted PIN, a card number from a 
card for said customer and a debit currency amount; 

subtracting said currency debit amount from the 
currency amount in said database corresponding to the 
received customer card number and PIN and updating said 
currency amount in said database; 

transmitting to said second remote terminal an 
authorization message for dispensing said currency debit 
amount to the customer if said currency debit amount is 
less than said currency amount in the database; and 

transmitting to said second remote terminal a 
message denying the dispensing of currency if said 
currency debit amount is greater than the currency amount 
in the database, 

8. A system for distributing currency or purchasing 
goods and services, comprising: 

means for generating a plurality of card numbers, 
each card number including an account number and a bank 
identification number, corresponding to card numbers 
encoded on a plurality of cards; 

a database on a central computer having at least a 
first field for said bank identification number, a second 
field for said account numbers, a third field for 
customer data, and a fourth field for a currency amount, 
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said bank identification number and said account numbers 
being loaded into said database, leaving said third and 
fourth fields blank, and a fifth field for a personal 
identification number (PIN) ; 

a first remote terminal for transmitting customer 
data f and ID number corresponding to a card number and a 
currency amount; 

means for entering said customer data and said 
currency amounts into said third and fourth fields, 
respectively, of said database corresponding to a bank 
identification number and an account number included in 
said card number and entering the PIN into said fifth 
field of said database corresponding to said customer; 

a second remote terminal for transmitting a customer 
inputted PIN, a card number from a card for said customer 
and a debit currency amount; 

means for subtracting said currency debit amount 
from the currency amount in said database corresponding 
to the received customer card number and PIN and updating 
said currency amount in said database; 

means for transmitting to said second remote 
terminal an authorization message for dispensing said 
currency debit amount to the customer if said currency 
debit amount is not greater than said currency amount in 
the database; 

means for transmitting to said second remote 
terminal a message denying the dispensing of currency if 
said currency debit amount is greater than the currency 
amount in the database. 
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